$ 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 から転記しておくことにした。大幅に加筆した。

編集者: すずき(更新: 2020年 9月 2日 16:58)

コメント一覧

コメントはありません。

この記事にコメントする

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 から転記しておくことにした。大幅に加筆した。

編集者: すずき(更新: 2020年 9月 2日 16:58)

コメント一覧

コメントはありません。

この記事にコメントする

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 はさすが良くできているなあと思います。

編集者: すずき(更新: 2020年 9月 2日 16:58)

コメント一覧

コメントはありません。

この記事にコメントする

2020年 2月 18日

permalink

編集する

Zephyr のブート処理 - ドライバの初期化情報の謎

目次: Zephyr を調べる - まとめリンク

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

ソースコードでわからなければバイナリを見るのも一つの手です。シンボルの一覧を調べます。

ドライバの初期化情報（シンボル）

$ riscv64-zephyr-elf-nm -n zephyr/build/zephyr/zephyr.elf

...

80002c38 D __device_PRE_KERNEL_1_start
80002c38 D __device_init_start
80002c38 d __device_sys_init_init_static_pools3
80002c44 d __device_uart_spike
80002c50 d __device_sys_init_uart_console_init0
80002c5c D __device_PRE_KERNEL_2_start
80002c5c d __device_sys_init_z_clock_driver_init0
80002c68 D __device_APPLICATION_start
80002c68 D __device_POST_KERNEL_start
80002c68 D __device_init_end

...

メモリイメージを図示すると下記のような感じで、前回のドライバの初期化処理が期待していると予想した並びになっています。違っていたら動きませんから、当たり前ですけども。

ドライバの初期化情報（メモリイメージ）

======== 80002c38 <-- __device_PRE_KERNEL_1_start, __device_init_start
__device_sys_init_init_static_pools3

======== 80002c44
__device_uart_spike

======== 80002c50
__device_sys_init_uart_console_init0

======== 80002c5c <-- __device_PRE_KERNEL_2_start
__device_sys_init_z_clock_driver_init0

======== 80002c68 <-- __device_POST_KERNEL_start, __device_APPLICATION_start, __device_init_end

POST_KERNEL と APPLICATION は何も要素を持っておらず、同じアドレスになってしまっているものの、確かにレベル順（PRE_KERNEL_1, PRE_KERNEL_2, POST_KERNEL, APPLICATION）に並んでいます。

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

$ 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
  ...

実体はあるのにソースコードに見当たらず、initlevel という変わった名前のセクションに置かれています。どうやら通常のグローバル変数や、static 変数ではなさそうです。

一番最初に出てくる __device_sys_init_init_static_pools3 がどうやって作られるのか、追いかけたらわかるかもしれません。部分一致でも良いので、それっぽい名前を grep すると kernel/mempool.c で見つかります。

mempool システムドライバの宣言


// zephyr/kernel/mempool.c

SYS_INIT(init_static_pools, PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_OBJECTS);


// zephyr/include/init.h

/* A counter is used to avoid issues when two or more system devices
 * are declared in the same C file with the same init function.
 */
#define Z_SYS_NAME(init_fn) _CONCAT(_CONCAT(sys_init_, init_fn), __COUNTER__)

/**
 * @def SYS_INIT
 *
 * @brief Run an initialization function at boot at specified priority
 *
 * @details This macro lets you run a function at system boot.
 *
 * @param init_fn Pointer to the boot function to run
 *
 * @param level The initialization level, See DEVICE_AND_API_INIT for details.
 *
 * @param prio Priority within the selected initialization level. See
 * DEVICE_AND_API_INIT for details.
 */
#define SYS_INIT(init_fn, level, prio) \
        DEVICE_AND_API_INIT(Z_SYS_NAME(init_fn), "", init_fn, NULL, NULL, level,\
        prio, NULL)


// (参考 1)
//  init_fn = init_static_pools
//  level   = PRE_KERNEL_1
//  prio    = CONFIG_KERNEL_INIT_PRIORITY_OBJECTS
//
//  Z_SYS_NAME(init_static_pools) = sys_init_init_static_pools3

マクロの嵐で面食らいますが、基本的に引数をそのまま渡していくだけなので 1つずつ見ればさほど難しくありません。

SYS_INIT() は mempool がシステムドライバであることを宣言するための API です（公式ドキュメント Device Driver Model - Zephyr Project Documentation, System Driver 節）。最終的には DEVICE_AND_API_INIT() が呼ばれます。実はこいつもマクロです、あとで紹介します。

若干難しいのは Z_SYS_NAME() でしょうか？このマクロは sys_init_ と、引数 init_fn とカウンタ（__COUNTER__）を連結したトークンを返します。

私の環境でビルドしたときは init_fn は init_static_pools で、__COUNTER__ は 3 でしたから、sys_init_ と init_static_pools と 3 が連結され、sys_init_init_static_pools3 になります。このトークンがDEVICE_AND_API_INIT() の第一引数に渡されます。

シンボル名が sys_init_init_... と init がダブっていて、変な名前だな？と思った方もいるでしょう、この Z_SYS_NAME() マクロが原因でした。ま、それはさておいて、続きを追いかけます。

ドライバの宣言マクロ


// zephyr/include/device.h

/**
 * @def DEVICE_AND_API_INIT
 *
 * @brief Create device object and set it up for boot time initialization,
 * with the option to set driver_api.
 *
 * @copydetails DEVICE_INIT
 * @param api Provides an initial pointer to the API function struct
 * used by the driver. Can be NULL.
 * @details The driver api is also set here, eliminating the need to do that
 * during initialization.
 */
#ifndef CONFIG_DEVICE_POWER_MANAGEMENT
#define DEVICE_AND_API_INIT(dev_name, drv_name, init_fn, data, cfg_info,  \
                            level, prio, api)                             \
        static const struct device_config _CONCAT(__config_, dev_name) __used \
        __attribute__((__section__(".devconfig.init"))) = {               \
                .name = drv_name, .init = (init_fn),                      \
                .config_info = (cfg_info)                                 \
        };                                                                \
        static Z_DECL_ALIGN(struct device) _CONCAT(__device_, dev_name) __used \
        __attribute__((__section__(".init_" #level STRINGIFY(prio)))) = { \
                .config = &_CONCAT(__config_, dev_name),                  \
                .driver_api = api,                                        \
                .driver_data = data                                       \
        }
#else
/*
 * Use the default device_pm_control for devices that do not call the
 * DEVICE_DEFINE macro so that caller of hook functions
 * need not check device_pm_control != NULL.
 */
#define DEVICE_AND_API_INIT(dev_name, drv_name, init_fn, data, cfg_info, \
                            level, prio, api)                            \
        DEVICE_DEFINE(dev_name, drv_name, init_fn,                       \
                      device_pm_control_nop, data, cfg_info, level,      \
                      prio, api)
#endif


//DEVICE_AND_API_INIT を展開すると最終的に下記のようになる
//
//変数名
//  _CONCAT(__config_, dev_name) = __config_sys_init_init_static_pools3
//構造体メンバー
//  drv_name = ""
//  init_fn = init_static_pools
//  cfg_info = NULL
//なので、

static const struct device_config __config_sys_init_init_static_pools3 __used
__attribute__((__section__(".devconfig.init"))) = {
        .name = "",
        .init = init_static_pools,
        .config_info = NULL
};


//変数名
//  _CONCAT(__device_, dev_name) = __device_sys_init_init_static_pools3
//セクション名
//  level = PRE_KERNEL_1
//  prio = 30
//  ".init_" #level STRINGIFY(prio) = ".init_PRE_KERNEL_130"
//構造体メンバー
//  _CONCAT(__config_, dev_name) = __config_sys_init_init_static_pools3
//  api  = NULL
//  data = NULL
//なので、

static Z_DECL_ALIGN(struct device) __device_sys_init_init_static_pools3 __used
__attribute__((__section__(".init_PRE_KERNEL_130"))) = {
        .config = &__config_sys_init_init_static_pools3,
        .driver_api = NULL,
        .driver_data = NULL
}


//(参考 2: DEVICE_AND_API_INIT の引数と値)
//  dev_name = Z_SYS_NAME(init_fn) = Z_SYS_NAME(init_static_pools) = sys_init_init_static_pools3
//  drv_name = ""
//  init_fn  = init_fn = init_static_pools
//  data     = NULL
//  cfg_info = NULL
//  level    = level = PRE_KERNEL_1
//  prio     = prio = CONFIG_KERNEL_INIT_PRIORITY_OBJECTS = 30
//  api      = NULL

//(参考 1: SYS_INIT の引数と値)
//  init_fn = init_static_pools
//  level   = PRE_KERNEL_1
//  prio    = CONFIG_KERNEL_INIT_PRIORITY_OBJECTS = 30

ちょっと長いですが DEVICE_AND_API_INIT() を見ていくと、最後は上記のように __config_sys_init_init_static_pools3 と __device_sys_init_init_static_pools3 の 2つの構造体の宣言に展開されることがわかります。

後者の __device_sys_init_init_static_pools3 は、先程 nm で zephyr.elf を見たときに出てきた、アイツです。それに加えて __device_sys_init_init_static_pools3 は、.init_PRE_KERNEL_130 という変な名前のセクションに配置されることもわかると思います。

理解が合っているか不安なときは、答え合わせとしてバイナリをチェックです。ビルド時に生成されるオブジェクト build/zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj のシンボルテーブルを objdump で確認するとわかりやすいです。

mempool.c.obj のシンボルテーブル

$ riscv64-zephyr-elf-objdump -t zephyr/build/zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj

...

00000000 l     O .bss.lock      00000000 lock
00000000 l    d  .devconfig.init        00000000 .devconfig.init
00000000 l     O .devconfig.init        0000000c __config_sys_init_init_static_pools3
00000000 l    d  .init_PRE_KERNEL_130   00000000 .init_PRE_KERNEL_130
00000000 l     O .init_PRE_KERNEL_130   0000000c __device_sys_init_init_static_pools3

...

セクション .init_PRE_KERNEL_130 に __device_sys_init_init_static_pools3 が配置されていることが確認できました。じゃあ、どうやって __device_PRE_KERNEL_1_start に含まれるようになるんでしょう？

続きはまた今度。

編集者: すずき(更新: 2020年 9月 2日 16:58)

コメント一覧

コメントはありません。

この記事にコメントする

2020年 2月 17日

permalink

編集する

Zephyr のブート処理 - ドライバの初期化まで

目次: Zephyr を調べる - まとめリンク

前回はリセット直後から C 言語の関数と出会うところまでを紹介しました。今回はドライバの初期化までを紹介します。

最初の C 言語の関数 _PrepC


// zephyr/arch/riscv/core/prep_c.c

void _PrepC(void)
{
        z_bss_zero();
#ifdef CONFIG_XIP
        z_data_copy();
#endif
#if defined(CONFIG_RISCV_SOC_INTERRUPT_INIT)
        soc_interrupt_init();
#endif
        z_cstart();
        CODE_UNREACHABLE;
}

ブート後に最初に出会う C 言語の関数 _PrepC() ですが、実はまだグローバル変数の初期化が終わっていませんので、この関数で初期化しています。z_bss_zero() は、ゼロ初期化される変数の領域（BSS）を 0 で初期化します。z_data_copy() は、変数領域を ROM から RAM にコピーします。

XIP（Execution In Place）が有効な場合、コード領域は Flash ROM などに配置され、CPU は ROM から直接コードを読み出して実行します。コード領域はそれで良いですが、変数の初期値も ROM におかれていて、そのままでは変数に書き込みできません。そのため ROM から RAM にコピーする必要があります。

最後の z_start() まで来ると、やっと普通の C 言語の世界です。

Zephyr の初期化処理


// zephyr/kernel/init.c

FUNC_NORETURN void z_cstart(void)
{

        ...

        /* perform basic hardware initialization */
        z_sys_device_do_config_level(_SYS_INIT_LEVEL_PRE_KERNEL_1);    //★ level = 0
        z_sys_device_do_config_level(_SYS_INIT_LEVEL_PRE_KERNEL_2);


// zephyr/include/init.h

#define _SYS_INIT_LEVEL_PRE_KERNEL_1    0
#define _SYS_INIT_LEVEL_PRE_KERNEL_2    1
#define _SYS_INIT_LEVEL_POST_KERNEL     2
#define _SYS_INIT_LEVEL_APPLICATION     3

初期化関数 z_cstart() は、色々ごちゃごちゃやっているのですが、真ん中あたりでドライバの初期化が行われます。レベルを PRE_KERNEL_1 (level 0), PRE_KERNEL_2 (level 1) の順に指定して、z_sys_device_do_config_level() という関数を呼びます。ちなみに POST_KERNEL (level 2), APPLICATION (level 3) はもっと後で、カーネルの初期化が終わった後に使われます。

初期化される対象はデバイスドライバ以外（後述の、メモリ割り当てシステムドライバなど）もありますけど、仕組みは同じみたいです。

ドライバの初期化処理


// zephyr/kernel/device.c

extern struct device __device_init_start[];
extern struct device __device_PRE_KERNEL_1_start[];
extern struct device __device_PRE_KERNEL_2_start[];
extern struct device __device_POST_KERNEL_start[];
extern struct device __device_APPLICATION_start[];
extern struct device __device_init_end[];

...

void z_sys_device_do_config_level(s32_t level)
{
        struct device *info;
        static struct device *config_levels[] = {
                __device_PRE_KERNEL_1_start,
                __device_PRE_KERNEL_2_start,
                __device_POST_KERNEL_start,
                __device_APPLICATION_start,
                /* End marker */
                __device_init_end,
        };

        for (info = config_levels[level]; info < config_levels[level+1];
                                                                info++) {
                int retval;
                const struct device_config *device_conf = info->config;
                ...

実装は上記のようになっています。level 0 の場合は __device_PRE_KERNEL_1_start[] という配列を先頭から処理します。他のレベルも同様ですね。

ドライバの初期化情報

======== <-- config_levels[0]
__device_PRE_KERNEL_1_start[0]
__device_PRE_KERNEL_1_start[1]
...
__device_PRE_KERNEL_1_start[n]
======== <-- config_levels[1]
__device_PRE_KERNEL_2_start[0]
__device_PRE_KERNEL_2_start[1]
...
__device_PRE_KERNEL_2_start[n]
======== <-- config_levels[2]
__device_POST_KERNEL_start[0]
__device_POST_KERNEL_start[1]
...
__device_POST_KERNEL_start[n]
======== <-- config_levels[3]
__device_APPLICATION_start[0]
__device_APPLICATION_start[1]
...
__device_APPLICATION_start[n]
======== <-- __device_init_end

このようにメモリ上に struct device がレベル順に並んでいることを期待しているようです。しかし配列の実体は C のソースコード上には存在しないように見えます。これは一体何者なんでしょう？

続きはまた今度。

編集者: すずき(更新: 2020年 9月 2日 16:58)

コメント一覧

コメントはありません。

この記事にコメントする

2020年 2月 16日

permalink

編集する

Zephyr のブート処理 - C 言語と出会うまで

目次: Zephyr を調べる - まとめリンク

以前（2020年 2月 1日の日記参照）Zephyr のエントリアドレスを調べましたが、もう少し先まで Zephyr のブート処理を調べます。復習となりますが、起動の仕方は下記のとおりです。

QEMU Spike モードで Zephyr を起動

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

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

...

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

ブート処理を追うにはデバッガが必須です（ブート部分でシリアル出力はできません）。これも前回の復習となりますが、QEMU は GDB でデバッグするためのオプションを持っています。オプション -s は GDB の接続を localhost:1234 で受け付けます、という意味で、オプション -S はエミュレータを Halted 状態で起動するという意味です。

GDB を接続すると、PC は 0x1000 を指しています。QEMU Spike モードはリセット後 0x1000 から実行を開始するようです。何度かステップ実行 si を行うと、0x1010 から 0x80000000 にジャンプするはずです。

QEMU ブート直後


   0x1000:      auipc   t0,0x0
   0x1004:      addi    a1,t0,32
   0x1008:      csrr    a0,mhartid
   0x100c:      lw      t0,24(t0)
=> 0x1010:      jr      t0        # 0x80000000 にジャンプ

0x1000: 0x00000297      0x02028593      0xf1402573      0x0182a283
0x1010: 0x00028067      0x00000000      0x80000000      0x00000000
                                        ↑この値をロードする

特に難しい話ではなく 0x1000 + 24 = 0x1018 からロード（0x80000000 が書かれている）して、ジャンプするだけです。ジャンプ先には Zephyr のエントリポイント __start がいます。

__start（0x80000000 ジャンプ後）


// zephyr/soc/riscv/riscv-privilege/common/vector.S

SECTION_FUNC(vectors, __start)
        .option norvc;

        /*
         * Set mtvec (Machine Trap-Vector Base-Address Register)
         * to __irq_wrapper.
         */
        la t0, __irq_wrapper
        csrw mtvec, t0

        /* Jump to __initialize */
        tail __initialize


// zephyr/arch/riscv/core/isr.S

/*
 * Handler called upon each exception/interrupt/fault
 * In this architecture, system call (ECALL) is used to perform context
 * switching or IRQ offloading (when enabled).
 */
SECTION_FUNC(exception.entry, __irq_wrapper)
        /* Allocate space on thread stack to save registers */
        addi sp, sp, -__z_arch_esf_t_SIZEOF

        /*
         * Save caller-saved registers on current thread stack.
         * NOTE: need to be updated to account for floating-point registers
         * floating-point registers should be accounted for when corresponding
         * config variable is set
         */
        RV_OP_STOREREG ra, __z_arch_esf_t_ra_OFFSET(sp)
        RV_OP_STOREREG gp, __z_arch_esf_t_gp_OFFSET(sp)
        RV_OP_STOREREG tp, __z_arch_esf_t_tp_OFFSET(sp)
        RV_OP_STOREREG t0, __z_arch_esf_t_t0_OFFSET(sp)
        ...

__start は __irq_wrapper 関数のアドレス（C 言語の関数ではないので、関数と呼ぶのは変ですが）を割り込みベクタに設定したあと、__initialize にジャンプします。

__initialize


// 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

boot_master_core:

#ifdef CONFIG_INIT_STACKS
        ...
#endif

        /*
         * Initially, setup stack pointer to
         * _interrupt_stack + CONFIG_ISR_STACK_SIZE
         */
        la sp, _interrupt_stack
        li t0, CONFIG_ISR_STACK_SIZE
        add sp, sp, t0

#ifdef CONFIG_WDOG_INIT
        call _WdogInit
#endif

        /*
         * Jump into C domain. _PrepC zeroes BSS, copies rw data into RAM,
         * and then enters kernel z_cstart
         */
        call _PrepC

最初に mhartid という CPU コアの ID を読み取ります。0 番をマスターコアとして、0 番以外のコアは割り込み待ち（wfi）の無限ループに入ります。マスターコアはスタックポインタの初期化を行って、_PrepC() 関数を呼び出します。

ここからやっと C 言語の世界です。

編集者: すずき(更新: 2020年 9月 2日 16:57)