コグノスケ

未来から過去へ表示

過去から未来へ表示(*)

もっと前

2020年2月19日 >>> 2020年2月28日

もっと後

2020年2月19日

permalink

編集する

Zephyrのブート処理 - ドライバの初期化情報とリンカーの妙技

目次: Zephyr

引き続き、ドライバの初期化に重要な役割を果たしている __device_PRE_KERNEL_1_start[] の謎を追っていきます。謎は「__device_PRE_KERNEL_1_start[] の実体はバイナリにあるもののソースコードには見当たらない」ことです。前回まででわかったことを復習すると、

__device_PRE_KERNEL_1_start[] の要素である初期化情報（__device_sys_init_init_static_pools3など）は、各ドライバの宣言SYS_INIT(), DEVICE_AND_API_INIT() などのAPIで作成される
__device_sys_init_init_static_pools3は .init_PRE_KERNEL_130セクションに配置される

配列の要素がどうやってできたかわかったので、残る謎は下記になります。

__device_PRE_KERNEL_1_start[] を構成する方法（__device_sys_init_init_static_pools3などを集めてくる方法）

これまた復習になりますが、__device_PRE_KERNEL_1_start[] はinitlevelセクションに配置されていました。

ドライバの初期化情報が配置されているセクション

$ riscv64-zephyr-elf-readelf -a zephyr/build/zephyr/zephyr.elf

...

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] vector            PROGBITS        80000000 000060 000010 00  AX  0   0  4
  [ 2] exceptions        PROGBITS        80000010 000070 000258 00  AX  0   0  4
  [ 3] text              PROGBITS        80000268 0002c8 002604 00  AX  0   0  4
  [ 4] sw_isr_table      PROGBITS        8000286c 0028cc 000080 00  WA  0   0  4
  [ 5] devconfig         PROGBITS        800028ec 00294c 000030 00   A  0   0  4
  [ 6] rodata            PROGBITS        8000291c 00297c 000305 00   A  0   0  4
  [ 7] datas             PROGBITS        80002c24 002c84 000014 00  WA  0   0  4
  [ 8] initlevel         PROGBITS        80002c38 002c98 000030 00  WA  0   0  4    ★ここに配置される★
  [ 9] _k_mutex_area     PROGBITS        80002c68 002cc8 000014 00  WA  0   0  4
  [10] bss               NOBITS          80002c80 002cdc 000140 00  WA  0   0  8
  [11] noinit            NOBITS          80002dc0 002cdc 000e00 00  WA  0   0 16
  ...

思い出していただきたいのは、配列の要素は .init_PRE_KERNEL_130セクションに置かれていて、initlevelセクションではなかったことです。つまり誰かがわざわざinitlevelセクションに置き直しています。

そんな芸当ができるのはリンカーしかいませんので、initlevelをキーワードにリンカースクリプトを探します。

initlevelセクションを作るリンカースクリプト

// zephyr/include/linker/common-ram.ld

...

        SECTION_DATA_PROLOGUE(initlevel,,)
        {
                DEVICE_INIT_SECTIONS()
        } GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)


// zephyr/include/linker/linker-defs.h

/*
 * generate a symbol to mark the start of the device initialization objects for
 * the specified level, then link all of those objects (sorted by priority);
 * ensure the objects aren't discarded if there is no direct reference to them
 */

#define DEVICE_INIT_LEVEL(level)                                \
                __device_##level##_start = .;                   \
                KEEP(*(SORT(.init_##level[0-9])));              \
                KEEP(*(SORT(.init_##level[1-9][0-9]))); \

/*
 * link in device initialization objects for all devices that are automatically
 * initialized by the kernel; the objects are sorted in the order they will be
 * initialized (i.e. ordered by level, sorted by priority within a level)
 */

#define DEVICE_INIT_SECTIONS()                  \
                __device_init_start = .;        \
                DEVICE_INIT_LEVEL(PRE_KERNEL_1) \
                DEVICE_INIT_LEVEL(PRE_KERNEL_2) \
                DEVICE_INIT_LEVEL(POST_KERNEL)  \
                DEVICE_INIT_LEVEL(APPLICATION)  \
                __device_init_end = .;          \
                DEVICE_BUSY_BITFIELD()          \

DEVICE_AND_API_INITの宣言を思い出すと、ドライバなどで宣言される初期化セクションの名前は .init_(level)(prio) のような名前でした。DEVICE_INIT_LEVEL() はその法則性に従ってセクションを集めます。最終的に集められたセクションは、全てinitlevelセクションに配置されます。

例えばDEVICE_INIT_SECTIONS() の2行目にあるDEVICE_INIT_LEVEL(PRE_KERNEL_1) ですと、.init_PRE_KERNEL_1(数字) という名前のセクションを集めます。

というわけで、やっと謎が解けました。マクロやリンカースクリプトの見事な連携プレイですね。

prioの制限とエラーチェック

実装を見て気づいたと思いますが、DEVICE_AND_API_INIT() のprioに渡せる数字は2桁が上限です。DEVICE_INIT_LEVEL() は [0-9] もしくは [1-9][0-9] のパターンしかマッチしません。

試しに優先度を3桁にするとどうなるでしょう？mempool.cではCONFIG_KERNEL_INIT_PRIORITY_OBJECTSをprioに渡していたので、menuconfigでコンフィグを変えてみます。

3桁のprioにしてはいけない

$ ninja menuconfig

General Kernel Options  --->
  Initialization Priorities  --->
    (30) Kernel objects initialization priority

このパラメータを300に変更すると…？

riscv64-zephyr-elf/bin/ld: Undefined initialization levels used.
collect2: error: ld returned 1 exit status

リンク時にエラーで怒られました。これはどうやっているのでしょう？実はそんなに難しくありません。initlevelセクションを作るときとほぼ同じ仕組みです。

initlevelで拾えなかった .init_* 系セクションの検知


// zephyr/include/linker/common-ram.ld

        /* verify we don't have rogue .init_<something> initlevel sections */
        SECTION_DATA_PROLOGUE(initlevel_error,,)
        {
                DEVICE_INIT_UNDEFINED_SECTION()
        }
        ASSERT(SIZEOF(initlevel_error) == 0, "Undefined initialization levels used.")


// include/linker/linker-defs.h

/* define a section for undefined device initialization levels */
#define DEVICE_INIT_UNDEFINED_SECTION()         \
                KEEP(*(SORT(.init_[_A-Z0-9]*))) \

このinitlevel_errorセクションでは、initlevelセクションが拾い損ねた .init_* 系のセクションを全て集めます。もし1つでもセクションが拾えた場合、initlevel_errorセクションのサイズが0ではなくなるため、ASSERTに引っかかる仕組みになっています。リンカースクリプトでASSERTやSORTができるとは知らなかったですね……。

エラーチェックもきっちり作られていてZephyrはさすが良くできているなあと思います。

編集者:すずき(2023/09/24 12:03)

コメント一覧

コメントはありません。

この記事にコメントする

2020年2月20日

permalink

編集する

Zephyrの16550シリアルドライバ

目次: Zephyr

先日はZepphyrをQEMUのSpikeモードに移植しましたが、SpikeモードだとCPU数は1以外選べないので、マルチプロセッサにできません。これは知りませんでした。最初に調べておけば良かったですね……。

マルチプロセッサでZephyrを動かしてみたかったので、QEMU RISC-V 32のvirtモード（qemu-system-riscv32のmachineをvirtにすること）に、前回同様にシリアルとメモリだけ動くようなSoCとボードの定義ファイルを作りました。

QEMU virtモードでは、シリアルのハードウェアとして16550をエミュレーションします。Zephyr側には既に16550用のドライバがあるので、わざわざ実装する必要もありません。とても楽です、素晴らしいです、とか何とか思いつつ動かしてみると、シリアルドライバがクラッシュします。んあー。

シリアルドライバが動かない理由

ZephyrをGDBで追うと16550のLCRレジスタを読もうとして、ロードアクセスフォルトが起きていました。アドレスのオフセットを見ると、0xcになっています。正しいオフセットは3のはずです。

シリアルドライバの実装を見ると、オフセットの計算が0x3 x 4 = 0xcとなっていて、おそらくレジスタサイズが4バイト単位だと思ってアクセスしているのでしょう。

世の中にはレジスタが4バイトの実装もあるかもしれませんが、残念なことにQEMUは由緒正しい（？）実装なので16550のレジスタは「1バイト」単位です。4バイト単位でアクセスすると、全く関係ない領域が破壊されます。困りました。

問題を解決するには、SoCの定義ファイルのどこか（soc.h辺りかな？）で、
#define DT_NS16550_REG_SHIFT 0
を定義し、レジスタのサイズが2^0つまり1バイト単位であることを16550シリアルドライバに教える必要があるみたいです。とても大事なことだと思いますが、全くドキュメントに書いていないように見えます。

そこそこコード見ないとわからないので、つらいです……。

シリアルドライバが動いた

無事シリアルが動作したので、QEMUを4 CPUのマルチプロセッサ設定で起動し、GDBで覗いてみます。

QEMU virtモードでマルチプロセッサと、その確認

$ qemu-system-riscv32 -nographic -machine virt -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/build/zephyr/zephyr.elf -cpu rv32 -smp cpus=4 -s -S

qemu-system-riscv32: warning: No -bios option specified. Not loading a firmware.
qemu-system-riscv32: warning: This default will change in a future QEMU release. Please use the -bios option to avoid breakages when this happens.
qemu-system-riscv32: warning: See QEMU's deprecation documentation for details.
*** Booting Zephyr OS build v2.2.0-rc1-123-gcaca3f60b012  ***
threadA: Hello World from QEMU RV32 virt board!
threadB: Hello World from QEMU RV32 virt board!
threadA: Hello World from QEMU RV32 virt board!
threadB: Hello World from QEMU RV32 virt board!
...


$ riscv64-zephyr-elf-gdb zephyr/build/zephyr/zephyr.elf 

...

Type "apropos word" to search for commands related to "word"...
Reading symbols from build/zephyr/zephyr.elf...

(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x00001000 in ?? ()

(gdb) info threads
  Id   Target Id                    Frame
* 1    Thread 1.1 (CPU#0 [running]) 0x00001000 in ?? ()
  2    Thread 1.2 (CPU#1 [running]) 0x00001000 in ?? ()
  3    Thread 1.3 (CPU#2 [running]) 0x00001000 in ?? ()
  4    Thread 1.4 (CPU#3 [running]) 0x00001000 in ?? ()

確かに4 CPUが存在していることがわかります。ZephyrのログはGDB側でcontinueすると出てきます。アプリケーションは、hello_worldではなくsamples/synchronizationを使っています。

メモ: 技術系の話はFacebookから転記しておくことにした。大幅に加筆した。

編集者:すずき(2023/09/24 12:06)

コメント一覧

コメントはありません。

この記事にコメントする

2020年2月21日

permalink

編集する

ZephyrとRISC-Vとマルチプロセッサ

目次: Zephyr

昨日（2020年2月20日の日記参照）の続きです。

シリアルのみですが、ZephyrをQEMU RISC-V 32のvirtモードに移植しました。やっとZephyrが4 CPUで動くぞ、などと思っていましたが、全然ダメでした。2つ目以降のCPUは全く動きませんでした。

CPU 0は動作するが、他のCPUはloop_slave_coreから動かない

$ riscv64-zephyr-elf-gdb zephyr/build/zephyr/zephyr.elf

(gdb) info threads
  Id   Target Id                    Frame
* 1    Thread 1.1 (CPU#0 [halted ]) 0x80000f70 in arch_cpu_idle ()
    at zephyr/soc/riscv/riscv-privilege/common/idle.c:21
  2    Thread 1.2 (CPU#1 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45
  3    Thread 1.3 (CPU#2 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45
  4    Thread 1.4 (CPU#3 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45

理由は簡単で、ZephyrのRISC-V版はSMPに対応していないからです。何を言ってるんだ？って？ええ、実は私も今この瞬間まで知りませんでした。ビックリしました。

リセット付近のソースコードをみると、

Zephyrのリセットベクタ


// zephyr/arch/riscv/core/reset.S

/*
 * Remainder of asm-land initialization code before we can jump into
 * the C domain
 */
SECTION_FUNC(TEXT, __initialize)
        /*
         * This will boot master core, just halt other cores.
         * Note: need to be updated for complete SMP support
         */
        csrr a0, mhartid
        beqz a0, boot_master_core

loop_slave_core:
        wfi
        j loop_slave_core

以上のように、はっきり書いてあります。SMPは一番大事な機能だと思っていただけに、未対応とは思わなんだ。

あー、今日の16550との戦いは一体何だったんだろう。しょんぼりですわ……。

メモ: 技術系の話はFacebookから転記しておくことにした。大幅に加筆した。

編集者:すずき(2023/09/24 12:06)