コグノスケ

エアコン浄化

今年の7月に（2018年7月17日の日記参照）エアコンを16℃設定1時間で浄化運転し、見事に嫌な臭いが消え去りました。しかし 8月末に再びエアコンが雑巾臭くなってしまいました（2018年8月21日の日記参照）。

エアコン18℃1時間運転をしてみました。相変わらずの威力で、無臭になりました。とはいえ、最近涼しくなってきているので、もうほとんどエアコン使わないなあ。

とかなんとか、思っていたのですが、困ったことに1日で雑巾臭さが復活してしまいました。といっても浄化する前より幾分もマシですから、しばらくこのまま使おうと思います。

どうも18℃だと浄化作用が弱かった？みたいです。最低の温度設定である16℃にすれば良かったかなあ？

引っ越し準備

引っ越し用の新品の段ボールが50箱以上届き、家が段ボールで埋め尽くされました。

届いた段ボールに荷物は一切入っておらず、綺麗に畳まれている状態ですが、それでも既に置くところがありません。これから段ボールに荷物を詰めていけば、より散らかる方に倒れます。

家が決まっていないとか、引っ越しの日程が近すぎることも心配ですが、果たして物理的に段ボールを置ききれるのか？も心配になってきました。

最終勤務日

今日はSocionextの最終勤務日でした。9月末退職ですが、9月末までは年休を取っています（それでも年休は半分以上余った）。

今から9月末までの3週間で、ほとんど土地勘のない東京で家探しをして、引っ越しを終えなければなりません。かなりスリリングな日程です。

やってたこと

Panasonic半導体社とSocionextで過ごした12年間は、ほぼ最初から最後までテレビ開発の仕事だったように思います。私がそうだっただけで、会社には他の仕事もあります。

技術的には幅広く関われました。Androidも多少齧れた（アプリ開発ではなくフレームワーク側）し、メディア再生のミドルウェア開発、デコーダやサウンドドライバ開発、LinuxやOSS活動もできました。面白かったです。

半導体会社はソフト、ハード、ボード設計、何でもやってますから、技術的には面白いところだと思います。機構設計はさすがにやってないか？

企業風土はPanasonic、富士通の流れを汲んでいて、いわゆる「日本の大企業」だと思います。平社員でしたから、他の事業部や組織は知りませんが…。

辞めた理由

何で辞めるの？と色んな人に聞かれましたが、別に嫌なことがあったわけじゃないし、特に理由はないです。強いて言えば10年も同じ分野に居たので、他分野にチャレンジしようとは思っていました。今回は偶然チャンスに恵まれただけです。

特に無いと答えると、またまた、そんな嘘を言わなくても良いんだよ！みたいなこと言われます。どうも、私は「常に会社に対して激烈な不満を持っていて」「最近何かがあって、ついにブチ切れて退職した」と思われていたようです。

いやいや、そんな爆弾みたいな奴が10年も会社に居ますか？有り得ないでしょ？ひどい言いがかりだなあ、もう……。

さくらのメールサーバーとgit send-email

自宅からちょっとしたLinuxのパッチを投げようと思って、さくらのメールサーバーをSMTPサーバーに指定して、git send-emailでメールを送ろうとしたらハマりました。

さくらのメールサーバーはSTARTTLSを使ってSMTP認証をせよ（メールソフトの設定 - さくらのサポート情報）とのことなので、.gitconfigの設定をこんな感じにしました。

[sendemail]
	smtpencryption = tls
	smtpserver = xxxx.sakura.ne.jp
	smtpuser = yyyy@xxxx.sakura.ne.jp
	smtpserverport = 587

実行してみると、Diedなんとかかんとか〜が表示され、メールが送れません。なんで？？

$ git --version
git version 2.18.0

$ git send-email --to 'xxxx' 0001-xxxx.patch

...snip...

Died at /usr/lib/git-core/git-send-email line 1523.

こういうトラブルのときは --smtp-debug=1を付ければ大体わかるはずです。

$ git send-email --to 'xxxx' --smtp-debug=1 0001-xxxx.patch

...snip...
Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>> (decoded)
Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>>
Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)<<< 235 2.0.0 OK Authenticated
Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>> MAIL FROM:<xxxxxxxx>
Died at /usr/lib/git-core/git-send-email line 1523.

なるほどなるほど？これはわかりませんね。どうなってるんだ、このサーバーは？

幸いなことに /usr/lib/git-core/git-send-emailはPerlのスクリプトですので、簡単にデバッグプリントを入れられます。

認証部分に当たりを付けて、小一時間、試行錯誤してみたところSMTP-AUTHにデフォルトでDIGEST-MD5が選択されると、失敗することがわかりました。じゃあ、強制的にSMTP-AUTHをPLAINにすればうまくいくよね？下記のように設定を変えてみました。

[sendemail]
	smtpencryption = tls
	smtpserver = xxxx.sakura.ne.jp
	smtpuser = yyyy@xxxx.sakura.ne.jp
	smtpserverport = 587
	smtpauth = PLAIN    # ★★この行を足した★★

無事メールが送れました。良かった良かった。

ROCK64のカーネルだけ元に戻したい

目次: ROCK64/ROCKPro64

ROCK64のカーネルを入れ替えていたら、動かないカーネルを書き込んでしまい、起動しなくなってしまいました。

Etcherを使えばSDカードを全て書き換え、起動可能な状態に戻すことができるものの、今までの作業や変更が全て消えてしまいます。

SDカード全書き換えはやりたくありません。なんとかカーネル「だけ」復旧できないでしょうか？

カーネルイメージのみ取り出す

Etcherのイメージファイルからカーネルだけ取り出して、上書きすれば復活するはずです。

Etcherの設定を変えていなければ、ダウンロードしたイメージファイルは、ユーザディレクトリのAppData\Roaming\pine64-installer\downloadedImageにあると思います。私はDebian Mateを使っていたので、files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img.xzというイメージファイル名でした。これをLinuxマシンにコピーします。

$ unxz files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img.xz
$ ls
files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img

# partx -v -a files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img
partition: none, disk: files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img, lower: 0, upper: 0
Trying to use '/dev/loop0' for the loop device
/dev/loop0: partition table type 'gpt' detected
range recount: max partno=7, lower=0, upper=0
/dev/loop0: partition #1 added
/dev/loop0: partition #2 added
/dev/loop0: partition #3 added
/dev/loop0: partition #4 added
/dev/loop0: partition #5 added
/dev/loop0: partition #6 added
/dev/loop0: partition #7 added

圧縮されているのでunxzで展開し、partx -aにてディスクイメージ内の全パーティションをloopbackデバイスに登録（※）しています。

ここまでくればHDDと同じようにマウントできます。

# mount /dev/loop0p6 rock64_boot

# ls -la rock64_boot/
total 41654
drwxr-xr-x 3 root      root         16384 Jan  1  1970 .
drwxr-xr-x 3 katsuhiro katsuhiro     4096 Sep  4 01:15 ..
-rwxr-xr-x 1 root      root      18606088 Dec 21  2017 Image
-rwxr-xr-x 1 root      root      18606088 Dec 21  2017 Image.bak
-rwxr-xr-x 1 root      root         42707 Dec 21  2017 dtb
-rwxr-xr-x 1 root      root         42707 Dec 21  2017 dtb.bak
drwxr-xr-x 2 root      root          2048 Oct 12  2017 extlinux
-rwxr-xr-x 1 root      root       2663325 Dec 21  2017 initrd.img
-rwxr-xr-x 1 root      root       2663386 Dec 21  2017 initrd.img.bak

ブート用のパーティションは6番目なので /dev/loop0p6をマウントしています。あとは欲しいファイルをコピーすればOK。

# umount /dev/loop0p6

# ls /dev/loop*
/dev/loop-control  /dev/loop0p3  /dev/loop0p7  /dev/loop4
/dev/loop0         /dev/loop0p4  /dev/loop1    /dev/loop5
/dev/loop0p1       /dev/loop0p5  /dev/loop2    /dev/loop6
/dev/loop0p2       /dev/loop0p6  /dev/loop3    /dev/loop7

# partx -v -d /dev/loop0
partition: none, disk: /dev/loop0, lower: 0, upper: 0
/dev/loop0: partition #1 removed
/dev/loop0: partition #2 removed
/dev/loop0: partition #3 removed
/dev/loop0: partition #4 removed
/dev/loop0: partition #5 removed
/dev/loop0: partition #6 removed
/dev/loop0: partition #7 removed

# ls /dev/loop*
/dev/loop-control  /dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
/dev/loop0         /dev/loop2  /dev/loop4  /dev/loop6


# losetup -l
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                         DIO LOG-SEC
/dev/loop0
             0      0         0  0 /home/katsuhiro/share/rock64/files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img
                                                                       0     512

# losetup -d /dev/loop0

# losetup -l

マウント時と同様にpartx -dでパーティションの登録を解除できます。しかしなぜか /dev/loop0の登録だけが残ります。気にせずlosetup -dで登録を解除すれば特に問題ないようですが、何かやり方が間違っているのかな？うーん…？？

（※）losetupと /dev/loop0のみでも、オフセットを指定するとか何とかして、頑張ればループバックマウントはできると思いますが、ディスクイメージにパーティションが複数含まれている場合はpartxを使った方が楽だと思います。

DTIの配ってくるIPアドレス

以前、高槻市でのWAKWAKの遅さに嫌気がさして、DTIに乗り換え（2017年6月6日の日記参照）ました。

DTIは時々、名前を逆引きできないIPアドレスを割り当ててくるようです。害はありませんが、WAKWAKのときは無かったことだったので、少し気になって調べてみました。

DTIから割り当てられたIPをwhoisで調べてみると、AT&Tが持っている144.156.0.0/16のアドレスでした。なぜかホスト名を逆引きできません。何でしょうね、このアドレス…？

毎回このアドレス帯なのか確かめるため、VDSL終端装置を再起動したところ、フリービット株式会社が持っている153.151.x.xというアドレスに変わりました。こちらはホスト名を逆引きできます。

何か事情があって2種類（もっとあるかもしれないけど）を使い分けているのでしょうか？不思議な動きです。

不思議なダメージ計算式

宇宙戦艦物語RPGというスマホのゲームをやっています。

攻略Wiki（サイトへのリンク）にダメージ計算式が載っていたので計算してみたのですが、微妙にゲーム中のダメージ値と一致しません。Wikiによると攻撃司令の加算値の計算は、

• Lv 1〜100までは +1
• Lv 101〜200までは +2
• Lv 201〜300までは +3

とあります。その通りに足すと攻撃司令Lv 9999ならば、ダメージ補正値が504900になるはずです。

しかし適当な武器（702式発掘超合剣Lv 1313、攻撃力1100 + 28885）と、計算で求めたダメージ補正値を足しても、ゲーム側で出てくるダメージと一致しません。計算ではダメージは534885になるはずなのに、実際のダメージは534985です。100ほどズレてしまいます。

計算式を色々変えていてLvが100で割り切れるときの加算を変な値にすると、計算結果とゲーム側のダメージが一致することに気づきました。例えばLv 99 → 100のとき、加算は +1ないし +2が素直ですが、あえて +1と +2を両方加算した +3にします。

変な計算式ですが、あえてこの変な計算式で求めると、攻撃司令Lv 9999の場合、ダメージ補正値が100増えて505000になり、計算結果とゲーム側のダメージとも一致しました。変なの。ゲーム側の計算がバグってるように思えて仕方がない。

Excelが止まる

この加算値の計算はループでやればすぐできますが、Excelで計算を始めてしまったので、Excelで頑張ってみました。意外と面倒です。やり方はいろいろあると思いますが、私の場合は、

MAX(MIN(H2-   0,100),0)* 1+
MAX(MIN(H2-  99,100),0)* 2+
MAX(MIN(H2- 199,100),0)* 3+
MAX(MIN(H2- 299,100),0)* 4+
...

こんな風に99行書いて求めました。セルが編集できないくらい重いです。

100で割り切れるところがバグっているのか、別の法則が発動しているのか、正確なところは確かめていないのでわかりません。

きちんと確かめるなら、攻撃司令のLvを下げていってLv 9900を跨げばわかります。幸いにもこのゲームは、敵に防御力の概念が無い（？）ようで、誰に攻撃をぶつけても攻撃力＝ダメージとなります。検証は簡単な部類だと思います。私はそこまでやっていませんけども……。

周回ゲー

宇宙戦艦物語RPGはどのように進めていても、いつかは必ず同じ面をグルグル何度も周回するゲームになります。それ自体は構わないのですが、ゲームバランスがマゾすぎます。

一番辛いのは「敵を〇〇体倒せ」系のLv上げで、多いステージでも1回に1500体しか敵が出ないのに、1つの艦種Lvカンストに9999 * 300体（= 300万体）倒さなきゃいけないことです。さらに良くないことに、艦種は23種類もあります。

私にはこのゲームを極めるのは無理そうです。

エアコンがまた臭くなった

先日（2018年7月17日の日記参照）エアコンを16℃設定1時間で浄化運転し、見事に嫌な臭いが消え去りました。しかし最近エアコンが雑巾臭くなってしまいました。

今年の夏はかなりヘビーに使っているとはいえ、浄化した効果が1か月しか持たないとなると、浄化が必要な頻度はかなり高そうです。

次の休みにでも、また浄化してみるかなあ。電気代がどうこうより、16℃運転の負荷で室外機が壊れそうで、心配ですけどね。

設定温度と臭い

エアコンが臭くなった状態で、設定温度を26℃に下げるとエアコンの嫌な臭いは一時的に消えます。

しかし28℃設定に上げると、かなり嫌な臭いがします。27℃設定だと日によって違います。おそらくその日の気温依存だと思われます。

また、我が家のエアコンは、運転停止すると自動的に送風運転が始まります。送風運転はほぼ確実に嫌な臭いがします。

どうもエアコンの熱交換が働いているとき（気温が高いとき、設定温度が低いとき）はあまり臭いがせず、働いていないとき（運転停止後の送風、設定温度が高いとき）はかなり嫌な臭いがするみたいです。

ROCK64のU-Bootスクリプトを読む

目次: ROCK64/ROCKPro64

先日（2018年7月23日の日記参照）ROCK64のU-Bootがdistro boot（U-Bootのdistro bootの説明）を使っていることはわかりましたが、もう少し具体的に調べておきます。

U-Bootは起動するとカウントダウンを始めます（Hit any key to stop autoboot... と表示される通り、何かキーを押すと止まります）。カウントが0になると、bootcmd環境変数に設定されたスクリプトを実行します。まずはそこから追います。

U-Boot 2017.09-g5aef9f7 (Oct 12 2017 - 09:11:39 +0000), Build: jenkins-linux-build-rock-64-136
   
Model: Pine64 Rock64
DRAM:  4 GiB
MMC:   rksdmmc@ff500000: 1, rksdmmc@ff520000: 0
*** Warning - bad CRC, using default environment
   
In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
normal boot
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0
=> 

=> print bootcmd
bootcmd=run distro_bootcmd

=> print distro_bootcmd
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done

=> print boot_targets
boot_targets=mmc0 mmc1 usb0 pxe dhcp

=> print bootcmd_mmc0
bootcmd_mmc0=setenv devnum 0; run mmc_boot
=> print bootcmd_mmc1
bootcmd_mmc1=setenv devnum 1; run mmc_boot

今回追いかける対象はSDカードからのブート（ROCK64の場合はmmc1として認識）ですので、mmc0, mmc1に注目します。bootcmd -> distro_bootcmd -> bootcmd_mmc1 -> mmc_bootと辿れます。ここまでは単純です。

環境変数:
devnum=1

----------

=> print mmc_boot
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi

----------

改行入れた版

if mmc dev ${devnum};
then
    setenv devtype mmc;
    run scan_dev_for_boot_part;
fi

----------

ifの条件式だけ実行した場合

=> mmc dev 0
Card did not respond to voltage select!    ★★★失敗する
mmc_init: -95, time 9

=> mmc dev 1
switch to partitions #0, OK    ★★★成功する
mmc1 is current device

このスクリプトはmmcデバイスを使えるかどうかチェックしています。devnum=1のときはmmc dev 1ですね。単独で実行するとわかりますが、このコマンドは成功し、デバイスが使用可能だとわかります。

デバイスが使用可能だとわかれば、scan_dev_for_boot_partを呼びます。

環境変数:
devnum=1
devtype=mmc

----------

=> print scan_dev_for_boot_part
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done

----------

改行入れた版

part list ${devtype} ${devnum} -bootable devplist;
env exists devplist || setenv devplist 1;
for distro_bootpart in ${devplist};
do
    if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then
        run scan_dev_for_boot;
    fi;
done

----------

最初の行

=> part list mmc 1 -bootable aaa    ★★★aaaは結果を格納する環境変数名（何を指定してもOK）
=> prin aaa
aaa=6                               ★★★boot可能パーティション番号が設定される

全部のパーティションを表示

=> part list mmc 1

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000040      0x00001f7f      "loader1"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   9bdf460d-26ba-4f39-b43f-e8289847b709
  2     0x00001f80      0x00001fff      "reserved1"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   50b5d36d-c009-4538-925e-a4ca3db6f3b9
  3     0x00002000      0x00003fff      "reserved2"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cbcf51cb-465b-47ee-a4ca-1c1ef59a8564
  4     0x00004000      0x00005fff      "loader2"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   fd2b2a59-fb82-4e11-827b-2297cdb0b74f
  5     0x00006000      0x00007fff      "atf"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   10194a7e-66c7-4340-a932-060295f19fba
  6     0x00008000      0x0003ffff      "boot"
        attrs:  0x0000000000000004                   ★★★6にboot可能フラグが存在
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   dbb99d65-e937-46a9-b740-256da98658a0
  7     0x00040000      0x01cf7fde      "root"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   55c58d2b-29ce-4c0d-bfec-414479e8ca46

----------

2行目

=> part list mmc 1 -bootable aaa
=> print aaa
aaa=6

=> env exists aaa || setenv aaa 1; ★★★左のコマンド結果が真のため、右のコマンドは実行されない
=> print aaa
aaa=6                              ★★★値は変わらない

=> setenv aaa                      ★★★環境変数を削除する
=> print aaa
## Error: "aaa" not defined

=> env exists aaa || setenv aaa 1; ★★★左のコマンド結果が偽のため、右のコマンドが実行される
=> print aaa
aaa=1                              ★★★値が1に設定される

----------

ifの条件式

=> fstype mmc 1:6 bootfstype
=> prin bootfstype
bootfstype=fat

1行目はboot可能フラグを持ったパーティションがあるかどうかを見ています。あればdevplist環境変数に「パーティションの番号」が設定されます。

2行目はboot可能フラグを持ったパーティションがなかったときのフェールセーフ処理で、先頭パーティション（1番）から起動を試みます。

ループ内のif文はパーティションのファイルシステム形式を取得して、bootfstypeという環境変数に設定します。ファイルシステムがわからない場合は処理をやめます。

あと、ループの条件文のところでdistro_bootpartにdevplistに格納されているパーティション番号（今回の場合は6）が設定されます。これも後で使われます。

環境変数:
devnum=1
devtype=mmc
distro_bootpart=6
bootfstype=fat

----------

=> print scan_dev_for_boot
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;

----------

改行入れた版

echo Scanning ${devtype} ${devnum}:${distro_bootpart}...;
for prefix in ${boot_prefixes};
do
    run scan_dev_for_extlinux;    ★★★成功すれば、以降は実行されない（他のscan_dev_xxxも同様）
    run scan_dev_for_scripts;
done;
run scan_dev_for_efi;

----------

boot_prefixesの内容

=> print boot_prefixes
boot_prefixes=/ /boot/

メッセージを出して、scan_dev_for_xxxのいずれかを実行します。これらのスクリプトは成功すると、OSつまりLinuxなどに制御が移りますので、成功したらU-Bootに戻りません。試す順は下記のようです。

• distro boot
• パーティションからU-Bootスクリプトをロード
• EFI boot

今回はdistro bootを使っていますので、scan_dev_for_extlinuxスクリプトを見ます。

環境変数:
devnum=1
devtype=mmc
distro_bootpart=6
bootfstype=fat
prefix=/ もしくは /boot/

----------

=> prin scan_dev_for_extlinux
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi

=> prin boot_extlinux
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf

----------

改行入れた版

-- scan_dev_for_extlinux

if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf;
then
    echo Found ${prefix}extlinux/extlinux.conf;
    run boot_extlinux;
    echo SCRIPT FAILED: continuing...;
fi

-- boot_extlinux

sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf

----------

ifの条件文

=> if test -e mmc 1:6 /extlinux/extlinux.conf; then echo OK; else echo NG; fi
OK
=> if test -e mmc 1:6 /boot/extlinux/extlinux.conf; then echo OK; else echo NG; fi
NG

----------

新出の環境変数

=> print scriptaddr
scriptaddr=0x00500000

----------

sysbootのヘルプ

=> sysboot
sysboot - command to get and boot from syslinux files

Usage:
sysboot [-p] <interface> <dev[:part]> <ext2|fat|any> [addr] [filename]
    - load and parse syslinux menu file 'filename' from ext2, fat
      or any filesystem on 'dev' on 'interface' to address 'addr'

ブートするパーティションにextlinux.confという名前の設定ファイルがあるかどうかを探し、あればboot_extlinuxスクリプトを呼びます。boot_extlinuxはsysbootコマンドを呼びます。

今まで設定してきた環境変数を総動員してあてはめると…、最終的には下記のコマンドが実行されることがわかります。

sysboot mmc 1:6 any 0x00500000 /extlinux/extlinux.conf

もちろん、このコマンドを単独で実行しても起動するはずです。

# cat extlinux/extlinux.conf
label kernel-4.4
    kernel /Image
    initrd /initrd.img
    fdt /dtb
    append earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#}

言い忘れてました。extlinux.confはこのような記述です。カーネルイメージ（Image）、initramfsイメージ（initrd.img）, デバイスツリーブロブ（*.dtb）のファイル名、カーネルに渡すコマンドラインを指定できます。

GRUBの設定ファイルに似ているけど、もっとシンプルですね。