Linuxカーネルのコマンドラインはブートローダーからどう渡されるのか？ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
先日参加した自作OSもくもく会で「Linuxカーネルのコマンドラインはブートローダーからどう渡されるのか？」のような話が聞こえたので、調べようと思い調べてみました。確認はLinux kernel v4.5とsystemd-bootの2016/05/02 23:00 JSTのコードです。 uefiじゃない環境も確認しようかなと思ってgrubのコードをgit cloneはしました。が、うちのメイン環境で使っているのはsystemd-bootだしってことで確認してません。 で、カーネルのコマンドラインは↓のようなやつですね。 masami@saga:~/codes$ cat /proc/cmdline initrd=\initramfs-4.6.0-rc5-ktest+.img root=/dev/sda2 rw crashkernel=256M コマンドラインをカーネルに渡すとしたら、どこかし
Linux/arm64のブートプロセスについてのメモ - Qiita
Linuxのブートプロセスを追うときに見るべきファイル(x86_64編)のarm64版のようなもの。 ブートストラップ linux/Documentation/arm64/booting.txt によると、現在のarm64用カーネルは、x86_64用カーネルが持つようなブートストラップの機能が存在しない。実際、arch/arm64/boot/以下にはx86_64のようなソースコード(head_64.S等)が存在しない。ブートローダがハードウェアの最低限の初期化をして、解凍された生のカーネルイメージ(ELFではない)を配置、エントリポイントにジャンプしてやらないといけない。カーネルに実行を移すときの要件も、booting.txtに書かれている。 ブートローダとしては、ubootやUEFIが使えると思われる。(Boot Wrapperというのも使えるみたいだが、今も使えるかは分からない。) a
Linuxのブートプロセスを追うときに見るべきファイル(x86_64編) - Qiita
4.0というか4/25時点のLinusツリーのHEAD リアルモードでbzImage(vmlinuz)の先頭から呼ばれる場合(LILOから呼ばれるときだっけ？) arch/x86/boot/header.S 圧縮されたカーネル(bzImage)の先頭にあるコード(setup.elf)のうちの一つ エントリポイント_startがある mainを呼ぶ arch/x86/boot/main.c mainがある いろいろハードウェアを初期化する go_to_protected_modeを呼ぶ arch/x86/boot/pm.c go_to_protected_modeがある setup_idtとかsetup_gdt等でプロテクトモードへ入る準備をする protected_mode_jumpでcode32_start(startup_32がある場所)へジャンプする startup_32は0x100
仙石浩明の日記: initramfs (initrd) の init を busybox だけで書いてみた
ブートパラメータとして「initrd=」を与えると、 ブートローダがイメージをメモリ上に読み込んでカーネルに渡す。 するとカーネルはそのイメージがファイルシステムなのか、 cpio アーカイブなのか調べる。 もしファイルの magic number が cpio であれば、 ramfs としてマウントする。 そして /init が実行可能ならば、 initramfs として扱い、 /init を起動する。 以上の条件が一つでも成立しない場合、 すなわち cpio アーカイブでない場合や、 /init が実行できない (/init が存在しない) 場合は、 initrd 扱いになるので注意が必要である。 すなわち RAM ディスクとしてマウントしようとするので、 カーネルに RAM ディスクドライバが組み込まれていなかったり、 「root=/dev/ram0」カーネルパラメータを指定していな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
