コグノスケ

2020年2月1日

link permalink link 編集する

Zephyrのエントリアドレス

目次: Zephyr

Zephyrをqemu_riscv32ボード向けにコンフィグし、ビルドディレクトリ下でninja runを実行すると、最終的に下記のコマンドが実行され、QMEUが起動します。

QEMUの起動コマンド
$ /usr/bin/qemu-system-riscv32 -nographic -machine sifive_e -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/build/zephyr/zephyr.elf -s -S

GDBで追うとわかりますが、QEMUの実行開始アドレスは0x1000です。0x1000には0x20400000にジャンプするコードだけが置かれています。

0x1000にあるコード

   0x1000:      lui     t0,0x20400
=> 0x1004:      jr      t0
   0x1008:      unimp
   0x100a:      unimp

HiFive1実機であれば0x20400000はQSPI Flashがマッピングされているアドレスです（SiFive FE310-G000 Manual v2p3を参照）。QEMUの場合はELFファイルbuild/zephyr/zephyr.elfのセクション情報通りに配置されます。

0x1000にあるコード
$ riscv64-zephyr-elf-readelf -a build/zephyr/zephyr.elf  | less

...

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        20400000 000094 000010 00  AX  0   0  4
  [ 2] exceptions        PROGBITS        20400010 0000a4 000258 00  AX  0   0  4
  [ 3] text              PROGBITS        20400268 0002fc 002ad4 00  AX  0   0  4
  [ 4] sw_isr_table      PROGBITS        20402d3c 002dd0 000200 00  WA  0   0  4
  [ 5] devconfig         PROGBITS        20402f3c 002fd0 000060 00   A  0   0  4
  [ 6] rodata            PROGBITS        20402f9c 003030 000215 00   A  0   0  4
  [ 7] datas             PROGBITS        80000000 003248 000018 00  WA  0   0  4
  [ 8] initlevel         PROGBITS        80000018 003260 000060 00  WA  0   0  4
  [ 9] _k_mutex_area     PROGBITS        80000078 0032c0 000014 00  WA  0   0  4
  [10] bss               NOBITS          80000090 0032e0 00013c 00  WA  0   0  8
  [11] noinit            NOBITS          800001d0 0032e0 000e00 00  WA  0   0 16

...

ジャンプ先の0x20400000にはvectorというセクションが対応していることがわかります。ELFファイルを逆アセンブルしてみると、

0x20400000にあるコード

zephyr/zephyr.elf:     file format elf32-littleriscv


Disassembly of section vector:

20400000 <__start>:

        /*
         * Set mtvec (Machine Trap-Vector Base-Address Register)
         * to __irq_wrapper.
         */
        la t0, __irq_wrapper
20400000:       00000297                auipc   t0,0x0
20400004:       01028293                addi    t0,t0,16 # 20400010 <__irq_wrapper>
        csrw mtvec, t0
20400008:       30529073                csrw    mtvec,t0

        /* Jump to __initialize */
        tail __initialize
2040000c:       4b40106f                j       204014c0 <__initialize>

以上のように __startという関数が居るようです。実装はzephyr/soc/riscv/riscv-privilege/common/vector.Sにあります。

Zephyrとデバイスツリー

このエントリポイントアドレスはどのように決まるのでしょう？Zephyrでは、ボード用のデバイスツリーzephyr/boards/riscv/qemu_riscv32/qemu_riscv32.dtsにあるFlashの先頭アドレスを変えるとELFのエントリポイント（0x20400000）も追従します。

ボード用のデバイスツリーのchosenノード

        chosen {
                zephyr,console = &uart0;
                zephyr,shell-uart = &uart0;
                zephyr,sram = &dtim;
                zephyr,flash = &flash0;
        };

このchosen以下を検知しているようです。スクリプトscripts/dts/gen_defines.pyを見ると、SPIのときだけ特殊処理になっていて、それ以外はregの値を先頭アドレスとみなしています。

Flashのサイズを見ている箇所

# zephyr/scripts/dts/gen_defines.py

...

def write_flash_node(edt):
    # Writes output for the top-level flash node pointed at by
    # zephyr,flash in /chosen

    node = edt.chosen_node("zephyr,flash")

    out_comment(f"/chosen/zephyr,flash ({node.path if node else 'missing'})")

    if not node:
        # No flash node. Write dummy values.
        out("FLASH_BASE_ADDRESS", 0)
        out("FLASH_SIZE", 0)
        return

    if len(node.regs) != 1:
        err("expected zephyr,flash to have a single register, has "
            f"{len(node.regs)}")

    if node.on_bus == "spi" and len(node.bus_node.regs) == 2:
        reg = node.bus_node.regs[1]  # QSPI flash
    else:
        reg = node.regs[0]

    out("FLASH_BASE_ADDRESS", hex(reg.addr))
    if reg.size:
        out("FLASH_SIZE", reg.size//1024)

...

FlashのアドレスはDT_FLASH_BASE_ADDRESSというマクロで参照できます。エントリーポイントを最終的に決めるのはリンカースクリプトです。SoCで独自のリンカースクリプトを実装することもできるようになっていますが、RISC-Vの多くのSoCは、下記のスクリプトを使っています。

エントリーポイントを決めている箇所

// zephyr/include/arch/riscv/common/linker.ld

MEMORY
{
#ifdef CONFIG_XIP
    ROM (rx)  : ORIGIN = DT_FLASH_BASE_ADDRESS, LENGTH = KB(DT_FLASH_SIZE)
#endif
    RAM (rwx) : ORIGIN = CONFIG_SRAM_BASE_ADDRESS, LENGTH = KB(CONFIG_SRAM_SIZE)
    /* Used by and documented in include/linker/intlist.ld */
    IDT_LIST  (wx)      : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

Zephyrのエントリポイントがどうやって決まるのか、少しわかった気がします。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月2日

link permalink link 編集する

Zephyr OSで遊ぼう その1 - ボードを追加してcmake

目次: Zephyr

先日（2020年1月31日の日記参照）RISC-V 32bit版のZephyr OSが動作しました。気分を変えて、別のボードへの移植に挑戦してみたいと思います。

名前は何でも良いのですが、とりあえずhogeボードということにします。-DBOARD=hogeを指定してcmakeを実行すると、そんなものはないと怒られ、猛烈な勢いでヘルプメッセージが出るとともに、サポートされているボードの一覧が出てきます。

存在しないボードを指定したときの、ボード一覧
$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
No board named 'hoge' found
see usage:

...

Supported Boards:

...

  riscv:
    hifive1
    hifive1_revb
    litex_vexriscv
    m2gl025_miv
    qemu_riscv32
    qemu_riscv64
    rv32m1_vega_ri5cy
    rv32m1_vega_zero_riscy
  x86:
    acrn
    gpmrb
    minnowboard
    qemu_x86_64
    qemu_x86_coverage
    qemu_x86
    qemu_x86_nommu
    up_squared

...

まず、この一覧にhogeボードを載せるのが第一段階です。ボードの一覧を調べているcmakeのスクリプトを見ます。

ボード一覧を調べている箇所

# zephyr/cmake/app/boilerplate.cmake

...

foreach(root ${BOARD_ROOT})
  # NB: find_path will return immediately if the output variable is
  # already set
  find_path(BOARD_DIR
    NAMES ${BOARD}_defconfig
    PATHS ${root}/boards/*/*
    NO_DEFAULT_PATH
    )
  if(BOARD_DIR AND NOT (${root} STREQUAL ${ZEPHYR_BASE}))
    set(USING_OUT_OF_TREE_BOARD 1)
  endif()

...

これで探しているように見えます。boards/*/* ディレクトリに「ボード名_defconfig」という名前のファイルがあれば良さそうです。足してからcmakeを再度、存在しないボード名（hoge2とかで良いです）で実行しましょう。

defconfigを足した後のボード一覧
$ mkdir boards/riscv/hoge
$ touch boards/riscv/hoge/hoge_defconfig

$ cmake -G Ninja -DBOARD=hoge2 ../samples/hello_world/

...

  riscv:
    hifive1
    hifive1_revb
    hoge        ★hogeが出てきた★
    litex_vexriscv
    m2gl025_miv
    qemu_riscv32
    qemu_riscv64
    rv32m1_vega_ri5cy
    rv32m1_vega_zero_riscy

...

やりました。ボードの一覧にhogeが出ました。BOARD=hogeにしてcmakeを実行しましょう。

defconfigを足した後のcmake
$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Selected BOARD hoge
Parsing zephyr/Kconfig
zephyr/scripts/kconfig/kconfig.py: Kconfig.zephyr:26: 'zephyr/boards/riscv/hoge/Kconfig.defconfig' not found (in 'source "$(BOARD_DIR)/Kconfig.defconfig"'). Check that environment variables are set correctly (e.g. $srctree, which is set to 'zephyr'). Also note that unset environment variables expand to the empty string.
CMake Error at zephyr/cmake/kconfig.cmake:214 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/app/boilerplate.cmake:461 (include)
  CMakeLists.txt:5 (include)

-- Configuring incomplete, errors occurred!

まだ色々とエラーが出ています。エラーメッセージはKconfig.defconfigがないと言っています。このファイルを足すと、今度はKconfig.boardがないと言われますので、両方とも足します。

Kconfig.defconfig, Kconfig.boardを足した後のcmake
$ touch boards/riscv/hoge/Kconfig.defconfig
$ touch boards/riscv/hoge/Kconfig.board

$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/boards/riscv/hoge/hoge_defconfig'
Merged configuration 'zephyr/samples/hello_world/prj.conf'

warning: <choice> (defined at boards/Kconfig:19) defined with type unknown

error: Aborting due to non-whitelisted Kconfig warning 'warning: <choice> (defined at boards/Kconfig:19)
defined with type unknown'. If this warning doesn't point to an actual problem, you can add it to
the whitelist at the top of zephyr/scripts/kconfig/kconfig.py.

CMake Error at zephyr/cmake/kconfig.cmake:214 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/app/boilerplate.cmake:461 (include)
  CMakeLists.txt:5 (include)


-- Configuring incomplete, errors occurred!

今度はchoiceが無いと言っています。エラーを出しているのは下記のcmakeファイルです。

エラーを出しているkconfig.cmake
# zephyr/cmake/kconfig.cmake

execute_process(
  COMMAND
  ${PYTHON_EXECUTABLE}
  ${ZEPHYR_BASE}/scripts/kconfig/kconfig.py
  ${input_configs_are_handwritten}
  ${KCONFIG_ROOT}
  ${DOTCONFIG}
  ${AUTOCONF_H}
  ${PARSED_KCONFIG_SOURCES_TXT}
  ${input_configs}
  WORKING_DIRECTORY ${APPLICATION_SOURCE_DIR}
  # The working directory is set to the app dir such that the user
  # can use relative paths in CONF_FILE, e.g. CONF_FILE=nrf5.conf
  RESULT_VARIABLE ret
  )
if(NOT "${ret}" STREQUAL "0")
  message(FATAL_ERROR "command failed with return code: ${ret}")
endif()

このままkconfig.pyを見ても良いですが、おそらく時間のムダです。親切なエラーメッセージが出ているからです。メッセージの言うとおりboards/Kconfigを見ます。

choiceのエラーの原因
# boards/Kconfig

...

# Note: $BOARD_DIR might be a glob pattern

choice
	prompt "Board Selection"

source "$(BOARD_DIR)/Kconfig.board"    ★このファイルが空★

endchoice

先ほど作成したKconfig.boardが空っぽだったため、choiceの選択肢が存在せず怒られているようです。書く内容については、別のボード（例えばzephyr/boards/riscv/qemu_riscv32/Kconfig.board）を参照すると良いと思います。今回はこんな内容にしました。

Kconfig.boardを書き換え

# SPDX-License-Identifier: Apache-2.0
 
config BOARD_HOGE
	bool "Hoge target"
	depends on SOC_RISCV_SIFIVE_FREEDOM

この定義だとSiFiveのFreedomが搭載されていることになりますが、depends onの先に手を出すには、SoCの定義を加えなければなりません。一度に紹介しても訳がわからないので、今回はボードに焦点を絞ります。

書き換えた後にもう一度cmakeを実行すると、成功します。

Kconfig.boardを書き換えた後にcmake実行
$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/boards/riscv/hoge/hoge_defconfig'
Merged configuration 'zephyr/samples/hello_world/prj.conf'
Configuration saved to 'zephyr/build/zephyr/.config'
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/katsuhiro/x-tools/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build


$ ninja

[0/1] Re-running CMake...
-- Zephyr version: 2.1.99
-- Selected BOARD hoge
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/build/zephyr/.config'
No change to 'zephyr/build/zephyr/.config'
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build
[5/83] Building C object zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj
FAILED: zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj
ccache /home/katsuhiro/x-tools/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc -DBUILD_VERSION=zephyr-v2.1.0-1471-g7e7a4426d835 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../kernel/include -I../arch/riscv/include -I../include -Izephyr/include/generated -I../soc/riscv/litex-vexriscv -isystem ../lib/libc/minimal/include -isystem /home/katsuhiro/x-tools/riscv64-zephyr-elf/lib/gcc/riscv64-zephyr-elf/8.3.0/include -isystem /home/katsuhiro/x-tools/riscv64-zephyr-elf/lib/gcc/riscv64-zephyr-elf/8.3.0/include-fixed -Os -imacroszephyr/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mabi=ilp32 -march=rv32ima -imacroszephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=zephyr/samples/hello_world=CMAKE_SOURCE_DIR -fmacro-prefix-map=zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj   -c zephyr/arch/riscv/core/offsets/offsets.c
In file included from ../include/sys/atomic.h:468,
                 from ../include/kernel_includes.h:21, 
                 from ../include/kernel.h:17,
                 from zephyr/arch/riscv/core/offsets/offsets.c:16:
zephyr/include/generated/syscalls/atomic.h:25:19: error: conflicting types for 'atomic_cas'
 static inline int atomic_cas(atomic_t * target, atomic_val_t old_value, atomic_val_t new_value)
                   ^~~~~~~~~~
In file included from ../include/kernel_includes.h:21, 
                 from ../include/kernel.h:17,
                 from zephyr/arch/riscv/core/offsets/offsets.c:16:
../include/sys/atomic.h:44:20: note: previous definition of 'atomic_cas' was here
 static inline bool atomic_cas(atomic_t *target, atomic_val_t old_value,

せっかくcmakeがうまくいった、と思ったのも束の間で、ninjaは見るのが嫌になるくらい大量のエラーを表示して失敗します。続きはまた今度。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月3日

link permalink link 編集する

Zephyr OSで遊ぼう その2 - ボードを追加してビルド

目次: Zephyr

前回ninjaを実行したときに嫌というほどエラーが出ました。エラーを追う前に、コンフィグがあっているかチェックしたいと思います。

ZephyrはLinux Kernelと似たコンフィグのシステム（Kconfig）を持っています。使い方もLinuxと似ており、ninja menuconfigとすると、ケバケバしい色（私の環境だと真っ白＋黄色になる……）の画面が表示されます。


menuconfigの画面

なぜかArchitectureがx86となっていたり、SoCがLiteXになっていたり、色々おかしいです。なぜこうなってしまったかは後にして、手当たり次第でそれらしい値に直すと、Board Selectionに今回追加したHoge targetが出現します。

menuconfigで手修正する箇所
$ ninja menuconfig

Architecture (x86 architecture)  --->
  ( ) RISCV architectureを選択

SoC/CPU/Configuration Selection (LiteX VexRiscv system implementation)  --->
  ( ) SiFive Freedom SOC implementationを選択

コンフィグがそれらしくなったらninjaでビルドします。

menuconfigで手修正後のビルド
$ ninja

zephyr/samples/hello_world/src/main.c:12:30: error: 'CONFIG_BOARD' undeclared (first use in this function); did you mean 'CONFIG_ARCH'?
  printk("Hello World! %s\n", CONFIG_BOARD);
                              ^~~~~~~~~~~~
                              CONFIG_ARCH

...

In file included from ../include/devicetree.h:12,
                 from ../soc/riscv/riscv-privilege/sifive-freedom/soc.h:15,
                 from ../include/arch/riscv/arch.h:25, 
                 from ../include/arch/cpu.h:23,
                 from ../include/kernel_includes.h:34, 
                 from ../include/kernel.h:17,
                 from zephyr/drivers/interrupt_controller/intc_plic.c:13:
zephyr/drivers/interrupt_controller/intc_plic.c: In function 'riscv_plic_irq_enable':
zephyr/include/generated/devicetree_fixups.h:8:25: error: 'DT_INST_0_SIFIVE_PLIC_1_0_0_IRQ_EN_BASE_ADDRESS' undeclared (first use in this function)
 #define DT_PLIC_IRQ_EN  DT_INST_0_SIFIVE_PLIC_1_0_0_IRQ_EN_BASE_ADDRESS
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

...

先程よりはマシになりましたが、まだエラーが山のように出ます。エラーの種類を大別するとCONFIG_BOARDの定義がない、DT_INST_ なんちゃらの定義がない、に分けられます。

最初のCONFIG_BOARDについては、いかにもボード側で定義しなければならなさそうな名前です。おなじみ他のボードを参照（boards/riscv/qemu_riscv32/Kconfig.defconfigなど）すると、Kconfig.boardで定義したconfig BOARD_HOGEが定義されているときに限り、CONFIG_BOARDにボード名のデフォルト値を設定していました。

つまり、このように書けば良いみたいです。

Kconfig.defconfig

# SPDX-License-Identifier: Apache-2.0

if BOARD_HOGE

config BOARD
	default "hoge"

endif

それ以外のDT_INST_ なんちゃらの定義については、少し複雑です。

Zephyrのデバイスツリーの扱い

Linuxではデバイスツリーファイル（*.dts）をデバイスツリーコンパイラdtcでコンパイルして、Flattened Device Tree（fdt）という形式のバイナリにします。fdtはカーネル内部に組み込んだり、ブートローダが起動時にカーネルに渡すなどして利用されます。

しかしZephyrはそもそもdtcを使わず、Pythonで処理します。デバイスツリーを書き間違えるとPythonスクリプトが怒ってくるのですが、これが理由みたいです。なんだと？と思う方はZephyrのドキュメント（Devicetree - Zephyr Project Documentation）をご参照ください。下記に引用します。

Note: In addition to the Python code above, the standard dtc DTS compiler is also run on the devicetree. This is just to catch any errors or warnings it generates. The output is unused.

ドキュメントのGenerated macrosの章を見ると、デバイスツリーからDT_INST_ なんちゃら、というマクロを生成する、という説明があり、ビルドエラーの原因となったマクロの仲間のようです。

デバイスツリーを足そう

推測するにデバイスツリーを何も定義していないことが、DT_INST_ なんちゃらマクロが存在しないことの原因ではないでしょうか？他のボード（boards/riscv/qemu_riscv32/qemu_riscv32.dtsなど）がデバイスツリーをどうしているか、見ながら真似してみます。

hoge.dts

/* SPDX-License-Identifier: Apache-2.0 */

/dts-v1/;

#include <riscv32-fe310.dtsi>

/ {
	model = "Hoge Board";
	compatible = "hoge,hoge";

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,sram = &dtim;
		zephyr,flash = &flash0;
	};
};

&gpio0 {
	status = "okay";
};

&uart0 {
	status = "okay";
	current-speed = <115200>;
	clock-frequency = <16000000>;
};

&spi0 {
	status = "okay";

	#address-cells = <1>;
	#size-cells = <0>;
	reg = <0x10014000 0x1000 0x20400000 0xc00000>;
	flash0: flash@0 {
		compatible = "issi,is25lp128", "jedec,spi-nor";
		size = <134217728>;
		label = "FLASH0";
		jedec-id = [96 60 18];
		reg = <0>;
		// Dummy entry
		spi-max-frequency = <0>;
	};
};

ほぼ全てコピーしただけです。ビルドしてみると、最後の方まで行きますが、いくつかシンボルがないと言われます。ログはフルパスが出ていて鬱陶しいので意味が残る程度に削っています。

デバイスツリー定義後のビルドエラー
$ ninja

...

riscv64-zephyr-elf/bin/ld: zephyr/arch/arch/riscv/core/libarch__riscv__core.a(isr.S.obj): in function `.L0 ':
zephyr/arch/riscv/core/isr.S:244: undefined reference to `_sw_isr_table'
riscv64-zephyr-elf/bin/ld: zephyr/kernel/libkernel.a(sched.c.obj): in function `z_reset_time_slice':
zephyr/kernel/sched.c:276: undefined reference to `z_clock_elapsed'
riscv64-zephyr-elf/bin/ld: zephyr/kernel/libkernel.a(timeout.c.obj): in function `elapsed':
zephyr/kernel/timeout.c:69: undefined reference to `z_clock_elapsed'
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.

これらのシンボルはドライバが提供するもののようですので、コンフィグでそれらしきものをONにしていきます。

コンフィグ追加
General Architecture Options  --->
  Interrupt Configuration  --->
    [ ] Use generated IRQ tablesを選択

General Kernel Options  --->
  [ ] Execute in place

Device Drivers  --->
  [ ] Serial Drivers  ----
    [ ] Enable UART Interrupt supportを選択
    [ ] SiFive Freedom serial driver (NEW)  ----
      [ ] Enable SIFIVE Port 0 (NEW)  ---- を選択

  [ ] Console drivers  ---
    [ ] Use UART for console (NEW) を選択

  Timer Drivers  --->
    [ ] RISCV Machine Timerを選択

  [ ] GPIO Drivers  ----
    [ ] SiFive Freedom Processor GPIO driver (NEW)  ---- を選択

  [ ] Enable board pinmux driver  ----
    [ ] SiFive Freedom SOC pinmux driver (NEW)  ----

このように全て手動で設定する必要はない（後々不要となる）ので、あまり詳しくなる必要はないですが、

SiFive関連
SiFiveのSoCなのでコンフィグを片っ端からONにしています
Use generated IRQ tables
_sw_isr_tableシンボルの定義に関わっています
Execute in Place（XIP）
ONにしないと、ビルドしたときにRAMサイズから溢れているというエラーで怒られます
RISCV Machine Timer
z_clock_elapsedシンボルの定義に関わっています

コンフィグがそれらしくなったらninjaでビルドして、実行します。

コンフィグ追加後、ビルド＆実行
$ ninja

...

Memory region         Used Size  Region Size  %age Used
             ROM:       13165 B        12 MB      0.10%
             RAM:        3808 B        16 KB     23.24%
        IDT_LIST:         569 B         2 KB     27.78%
[98/98] Linking C executable zephyr/zephyr.elf

$ /usr/bin/qemu-system-riscv32 -nographic -machine sifive_e -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel /home/katsuhiro/share/projects/oss/zephyr/build/zephyr/zephyr.elf

*** Booting Zephyr OS build zephyr-v2.1.0-1471-g7e7a4426d835  ***
Hello World! hoge

実行できました。Hello Worldの後ろがボード名（CONFIG_BOARD）です。無事、アプリがhogeボード上で動いたということですね。次回は面倒くさかった手動コンフィグの撲滅に挑みます。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月4日

link permalink link 編集する

Zephyr OSで遊ぼう その3 - ボードのデフォルトコンフィグ

目次: Zephyr

前回はデフォルトコンフィグがx86になっていたり、ドライバを有効にしないとリンクエラーになったり、おかしなことが起きていました。対策として手動でコンフィグを変えまくりましたが、本来は必要ありません。Zephyrのボード定義では、ボードごとにデフォルトコンフィグを持つことができるからです。

他のボード（zephyr/boards/riscv/qemu_riscv32/qemu_riscv32_defconfigなど）を見ると、ボード名_defconfigというファイルの中にCONFIG_ABCD=yという文がたくさんあります。このファイルに追加すると反映されそうです。
（2/19訂正: CONFIG_SYS_CLOCK_TICKS_PER_SEC=100を追加しないとタイマー割り込みが入りすぎて動かなくなるため、修正しました）

ボードのdefconfig: zephyr/boards/riscv/hoge/hoge_defconfig

# SPDX-License-Identifier: Apache-2.0

CONFIG_RISCV=y
CONFIG_SOC_SERIES_RISCV_SIFIVE_FREEDOM=y
CONFIG_SOC_RISCV_SIFIVE_FREEDOM=y
CONFIG_BOARD_HOGE=y
CONFIG_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_SERIAL=y
CONFIG_UART_SIFIVE=y
CONFIG_UART_SIFIVE_PORT_0=y
CONFIG_UART_CONSOLE=y
CONFIG_PLIC=y
CONFIG_PINMUX=y
CONFIG_PINMUX_SIFIVE=y
CONFIG_RISCV_MACHINE_TIMER=y
CONFIG_GPIO=y
CONFIG_GPIO_SIFIVE=y
CONFIG_SYS_CLOCK_TICKS_PER_SEC=100
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=10000000

CONFIG_BOARD_HOGEを除けば、ほぼqemu_riscv32_defconfigと同じです。

ボードのdefconfigを追加した後のcmakeとビルド
$ cd build
$ rm -r *

$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
-- Loading zephyr/boards/riscv/hoge/hoge.dts as base
Devicetree header saved to 'zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/boards/riscv/hoge/hoge_defconfig'
Merged configuration 'zephyr/samples/hello_world/prj.conf'
Configuration saved to 'zephyr/build/zephyr/.config'
Kconfig header saved to 'zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/katsuhiro/x-tools/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build


$ ninja

[0/1] Re-running CMake...
-- Zephyr version: 2.1.99
-- Selected BOARD hoge
-- Loading zephyr/boards/riscv/hoge/hoge.dts as base
Devicetree header saved to 'zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/build/zephyr/.config'
No change to configuration in 'zephyr/build/zephyr/.config'
No change to Kconfig header in 'zephyr/build/zephyr/include/generated/autoconf.h'
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build
[97/102] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
             ROM:       12761 B        12 MB      0.10%
             RAM:        4048 B        16 KB     24.71%
        IDT_LIST:         553 B         2 KB     27.00%
[102/102] Linking C executable zephyr/zephyr.elf

この状態でcmakeから実行すると、ビルド時に文句を言われなくなります。buildディレクトリには、以前cmakeを実行したときの設定ファイルが残っていますので、一度全て削除してから再度cmakeを実行した方が良いでしょう。特に -DBOARDを変更するときは削除したほうが良いです（cmakeにも同様の内容を注意されるはず）。

次回以降は、独自のSoCの追加に挑もうと思います。

補足: デバイスツリーとDT_INST_ マクロの関係

前回は説明を省きましたが、デバイスツリーからDT_INST_ なんとかマクロへの変換ルールは下記にあります。

DT_INST_ マクロを生成している箇所

# zephyr/cmake/dts.cmake

...

  #
  # Run gen_defines.py to create a .conf file and a header file
  #

  set(CMD_NEW_EXTRACT ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/dts/gen_defines.py
  --dts ${BOARD}.dts.pre.tmp
  --bindings-dirs ${DTS_ROOT_BINDINGS}
  --conf-out ${DEVICETREE_CONF}
  --header-out ${DEVICETREE_UNFIXED_H}
  --dts-out ${PROJECT_BINARY_DIR}/zephyr.dts # As a debugging aid
  )

...


# zephyr/scripts/dts/gen_defines.py

def main():
    global conf_file
    global header_file
    global flash_area_num

    ...

    for node in sorted(edt.nodes, key=lambda node: node.dep_ordinal):
        write_node_comment(node)

        # Flash partition nodes are handled as a special case. It
        # would be nicer if we had bindings that would let us
        # avoid that, but this will do for now.
        if node.name.startswith("partition@"):
            write_flash_partition(node, flash_area_num)
            flash_area_num += 1

        if node.enabled and node.matching_compat:
            write_regs(node)
            write_irqs(node)
            write_props(node)
            write_clocks(node)
            write_spi_dev(node)
            write_bus(node)
            write_existence_flags(node)

    ...

def write_existence_flags(node):
    # Generate #defines of the form
    #
    #   #define DT_INST_<instance no.>_<compatible string> 1
    #
    # for enabled nodes. These are flags for which devices exist.

    for compat in node.compats:
        instance_no = node.edt.compat2enabled[compat].index(node)
        out(f"INST_{instance_no}_{str2ident(compat)}", 1)

...

def str2ident(s):
    # Converts 's' to a form suitable for (part of) an identifier

    return s.replace("-", "_") \
            .replace(",", "_") \
            .replace("@", "_") \
            .replace("/", "_") \
            .replace(".", "_") \
            .replace("+", "PLUS") \
            .upper()

基本的にノードのcompatibleがそのまま使われますが、C言語のマクロ名として使用できない文字はアンダースコアに置換されます。compatibleは小文字で書くことが多いですが、マクロ名は大文字に変換しています。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月5日

link permalink link 編集する

Zephyr OSで遊ぼう その4 - 独自のSoC定義

目次: Zephyr

Hogeボードの定義を一通り実装しました。HogeボードのSoCはqemu_riscv32と同じSiFive FE310にしたことを覚えているでしょうか？Zephyrの移植に興味のある方からすると「ボード名を変えただけで、qemu_riscv32のコピーでは？」と感じるはずです。そんな悲しみの声にお答えすべく、次はSoCの変更を行います。

今回、ターゲットとするSoCはQEMUのSpikeモードです。このモードは、特別なハードウェアが必要なく手軽、偶然にも現状のZephyrが対応していない、簡単なドライバの実装が1つだけ必要、など学習にピッタリです。

Spikeはシミュレータのみで、物理的に存在するSoCではありません。ですが名前がないと説明しづらいので、以降の説明ではSpike SoCと呼びます。

RISC-V SoCディレクトリの構造とSpike SoCの定義場所

将来複雑になるかもしれませんが、今は簡単な構造です。zephyr/soc/riscvの下にSoCが定義されており、litex-vexriscv（LiteX VexRiscv）, openisa_rv32m1（OpenISA RV32M1）, riscv-privilege（RISC-V Priviledged Architecture対応SoC）の3つのディレクトリが存在しています。このうちriscv-privilegeは、さらに内部にいくつかのSoCの定義を抱えています。

SpikeはRISC-V Priviledgedに対応しているので、今回はriscv-privilegeシリーズの1つとして、新たなSoCを定義すると良さそうです。

ボードの定義を改造

Hogeボードの定義を見直してみると、Kconfig.boardに "depends on SOC_RISCV_SIFIVE_FREEDOM" の記述があり、hoge.dtsに #include <riscv32-fe310.dtsi> の記述があります。とりあえずこれを下記のように変更します。

Kconfig.boardとhoge.dtsの変更点

diff --git a/boards/riscv/hoge/Kconfig.board b/boards/riscv/hoge/Kconfig.board
index 7ece0d6dee..c90614a391 100644
--- a/boards/riscv/hoge/Kconfig.board
+++ b/boards/riscv/hoge/Kconfig.board
@@ -2,4 +2,4 @@

 config BOARD_HOGE
        bool "Hoge target"
-       depends on SOC_RISCV_SIFIVE_FREEDOM
+       depends on SOC_RISCV_SPIKE


diff --git a/boards/riscv/hoge/hoge.dts b/boards/riscv/hoge/hoge.dts
index 21678f49ea..ee0c6589c4 100644
--- a/boards/riscv/hoge/hoge.dts
+++ b/boards/riscv/hoge/hoge.dts
@@ -2,7 +2,7 @@

 /dts-v1/;

-#include <riscv32-fe310.dtsi>
+#include <riscv32-spike.dtsi>

 / {
        model = "Hoge";

この状態でcmakeをやり直します。念のためbuildディレクトリのファイルを全て削除してから、実行したほうが良いでしょう。

Kconfig.boardとhoge.dtsを変更してcmake
$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/

-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
-- Loading zephyr/boards/riscv/hoge/hoge.dts as base
In file included from <command-line>:
zephyr/boards/riscv/hoge/hoge.dts:5:10: fatal error: riscv32-spike.dtsi: No such file or directory
 #include <riscv32-spike.dtsi>
          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
CMake Error at zephyr/cmake/dts.cmake:140 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/app/boilerplate.cmake:460 (include)
  CMakeLists.txt:5 (include)


-- Configuring incomplete, errors occurred!

エラーをみるにriscv32-spike.dtsiがないと言って怒られているようですから、追加しましょう。

SoCのデバイスツリー

Zephyrのデバイスツリーはzephyr/dts以下にあります。今回はRISC-V一派のSoCを追加しますから、zephyr/dts/riscvの下にriscv32-spike.dtsiを作りましょう。

riscv32-spike.dtsi

/* SPDX-License-Identifier: Apache-2.0 */

/ {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "spike-dev";
        model = "spike";
        soc {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "spike-soc", "simple-bus";
                ranges;

                clint: clint@2000000 {
                        compatible = "riscv,clint0";
                        reg = <0x02000000 0x10000>;
                        reg-names = "control";
                };

                mem: mem@80000000 {
                        compatible = "spike,mem";
                        reg = <0x80000000 0x4000>;
                        reg-names = "mem";
                };

                uart0: serial {
                        compatible = "spike,uart-spike";
                        label = "uart_0";
                };
        };
};

最低限のデバイスだけ定義しています。

clint
割り込みコントローラ（Core Local Interruptor）です。タイマーのレジスタ（mtime, mtimecmp）を持っているコアです。
mem
SRAM領域です。QEMUは数百MBくらいメモリ領域があった気がしますが、そんなに要らないので16KBにしています。
uart0
シリアルデバイスです。実はこの名前は適切ではありません。Spikeは特殊なゲスト、ホスト間の通信により文字出力を実現していて、UARTハードウェアを模している訳ではないからです。レジスタ領域の定義が不要なのも、ハードウェアアクセスではないからです。

このファイルを加えてもまだcmakeに怒られます。Spike SoC用のデバイスツリーに出てこないノード（gpio, spiなど）を参照している箇所があるためです。ボード側の定義からばっさり削除します。

hoge.dtsのさらなる変更

diff --git a/boards/riscv/hoge/hoge.dts b/boards/riscv/hoge/hoge.dts
index 21678f49ea..e572d5a769 100644
--- a/boards/riscv/hoge/hoge.dts
+++ b/boards/riscv/hoge/hoge.dts
@@ -11,34 +11,10 @@
        chosen {
                zephyr,console = &uart0;
                zephyr,shell-uart = &uart0;
-               zephyr,sram = &dtim;
-               zephyr,flash = &flash0;
+               zephyr,sram = &mem;
        };
 };
 
-&gpio0 {
-       status = "okay";
-};
-
 &uart0 {
        status = "okay";
-       current-speed = <115200>;
-       clock-frequency = <16000000>;
-};
-
-&spi0 {
-       status = "okay";
-
-       #address-cells = <1>;
-       #size-cells = <0>;
-       reg = <0x10014000 0x1000 0x20400000 0xc00000>;
-       flash0: flash@0 {
-               compatible = "issi,is25lp128", "jedec,spi-nor";
-               size = <134217728>;
-               label = "FLASH0";
-               jedec-id = [96 60 18];
-               reg = <0>;
-               // Dummy entry
-               spi-max-frequency = <0>;
-       };
 };

これでもまだcmakeは通過できません。長くなってきましたので、続きはまた今度。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月6日

link permalink link 編集する

Zephyr OSで遊ぼう その5 - 独自のSoC定義（続き）

目次: Zephyr

今回はcmakeをパスするまで頑張ります。

エラー内容の調査

今後の方針のためcmakeのエラーを見ます。どうやらSOC_FAMILY_RISCV_PRIVILEGEがないとか、SOC_SERIES_RISCV_SPIKEとは何だ？とか、Kconfig周りの設定で怒っているようです。何も定義していないので当然ですね。

hoge.dtsを変更してcmakeしたときのエラー
warning: UART_CONSOLE (defined at drivers/console/Kconfig:47) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL_HAS_DRIVER (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html and/or look up
UART_CONSOLE in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


warning: RISCV_MACHINE_TIMER (defined at drivers/timer/Kconfig:153) was assigned the value 'y' but
got the value 'n'. Check these unsatisfied dependencies: SOC_FAMILY_RISCV_PRIVILEGE (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_RISCV_MACHINE_TIMER.html and/or look
up RISCV_MACHINE_TIMER in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.


warning: The choice symbol BOARD_HOGE (defined at boards/riscv/hoge/Kconfig.board:3) was selected
(set =y), but no symbol ended up as the choice selection. See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BOARD_HOGE.html and/or look up
BOARD_HOGE in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


zephyr/boards/riscv/hoge/hoge_defconfig:4: warning: attempt to assign the value 'y' to the undefined symbol SOC_SERIES_RISCV_SPIKE

zephyr/boards/riscv/hoge/hoge_defconfig:5: warning: attempt to assign the value 'y' to the undefined symbol SOC_RISCV_SPIKE

error: Aborting due to Kconfig warnings

CMake Error at zephyr/cmake/kconfig.cmake:216 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/app/boilerplate.cmake:461 (include)
  CMakeLists.txt:5 (include)

すぐにKconfigを追加と行きたいところですが、その前に少しやることがあります。

ボードのdefconfigを見直す

Hogeボードのdefconfigで余計なもの（SiFive FE310 SoC用の設定）を定義しているので、削りましょう。SiFive由来のドライバの設定、前回のデバイスツリーで定義していないPINMUXやGPIOの設定を削ります。

hoge_defconfigからSiFive用の設定を削る

diff --git a/boards/riscv/hoge/hoge_defconfig b/boards/riscv/hoge/hoge_defconfig
index 3f9626815f..32c4e9e90d 100644
--- a/boards/riscv/hoge/hoge_defconfig
+++ b/boards/riscv/hoge/hoge_defconfig
@@ -1,19 +1,12 @@
 # SPDX-License-Identifier: Apache-2.0
 
 CONFIG_RISCV=y
-CONFIG_SOC_SERIES_RISCV_SIFIVE_FREEDOM=y
-CONFIG_SOC_RISCV_SIFIVE_FREEDOM=y
+CONFIG_SOC_SERIES_RISCV_SPIKE=y
+CONFIG_SOC_RISCV_SPIKE=y
 CONFIG_BOARD_HOGE=y
 CONFIG_CONSOLE=y
 CONFIG_PRINTK=y
 CONFIG_SERIAL=y
-CONFIG_UART_SIFIVE=y
-CONFIG_UART_SIFIVE_PORT_0=y
 CONFIG_UART_CONSOLE=y
-CONFIG_PLIC=y
-CONFIG_PINMUX=y
-CONFIG_PINMUX_SIFIVE=y
 CONFIG_RISCV_MACHINE_TIMER=y
-CONFIG_GPIO=y
-CONFIG_GPIO_SIFIVE=y
 CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=10000000

これで余計なコンフィグが原因で怒られることはないはずです。

SoC用のKconfigの追加

基本的にSoCのKconfigを追加する場合、zephyr/soc/アーキテクチャ名/SoC名/Kconfig.socを足せば良いですが、RISC-V Privileged系のSoCは少し様子が違い、Kconfigが2段構成になります。

Kconfigの依存関係
# zephyr/soc/Kconfig

  source "$(SOC_DIR)/$(ARCH)/*/Kconfig.soc"


# zephyr/soc/riscv/riscv-privilege/Kconfig.soc

  source "soc/riscv/riscv-privilege/*/Kconfig.series"

ファイルを足すべき場所がわかりました。早速Kconfig.seriesを足します。内容は隣にあるSiFiveのディレクトリ（sifive-freedom）などを参考にします。

zephyr/soc/riscv/riscv-privilege/spike/Kconfig.series

# RISCV_SPIKE SOC implementation

# SPDX-License-Identifier: Apache-2.0

config SOC_SERIES_RISCV_SPIKE
        bool "SPIKE series SOC implementation"
        depends on RISCV
        select SOC_FAMILY_RISCV_PRIVILEGE
        help
          Enable support for Spike series SOC

再度cmakeを実行するとSOC_SERIES_RISCV_SPIKEのエラーが消えるはずです。残りのSOC_RISCV_SPIKEはどこで定義すべきでしょうか？

RISC-V PrivilegedのKconfigは2つある

RISC-V Privilegedや他のディレクトリを見ると気づくと思いますが、SoCのKconfigには2つ系列があります。

riscv-privilege/Kconfig.soc -> riscv-privilege/spike/Kconfig.seriesのラインと、
riscv-privilege/Kconfig -> riscv-privilege/spike/Kconfig.socのラインです。先程、追加したのは前者です。名前が紛らわしいのはRISC-V Privileged系列の実装の良くないところですね……。

RISC-V PrivilegedのKconfig依存関係（再整理）

# zephyr/Kconfig

  source "Kconfig.zephyr"


# zephyr/Kconfig.zephyr

  source "$(SOC_DIR)/Kconfig"    # SOC_DIR = soc


# zephyr/soc/Kconfig

  choice
  	prompt "SoC/CPU/Configuration Selection"

  source "$(SOC_DIR)/$(ARCH)/*/Kconfig.soc"    # soc/riscv/riscv-privilege/Kconfig.soc

  endchoice

  menu "Hardware Configuration"
  osource "$(SOC_DIR)/$(ARCH)/Kconfig"
  osource "$(SOC_DIR)/$(ARCH)/*/Kconfig"    # soc/riscv/riscv-privilege/Kconfig


# zephyr/soc/riscv/riscv-privilege/Kconfig.soc

  source "soc/riscv/riscv-privilege/*/Kconfig.series"


# zephyr/soc/riscv/riscv-privilege/Kconfig

  config SOC_FAMILY_RISCV_PRIVILEGE    # riscv-privilege/spike/Kconfig.seriesのselectで有効にする
  config SOC_FAMILY
  config RISCV_HAS_PLIC

  ...

  source "soc/riscv/riscv-privilege/*/Kconfig.soc"

仕組みがわかったところで、後者のKconfig.socも追加しましょう。内容はやはりSiFiveのKconfigを参考にします。ありがとうSiFiveさん。

zephyr/soc/riscv/riscv-privilege/spike/Kconfig.soc

# RISCV_SPIKE SOC configuration options

# SPDX-License-Identifier: Apache-2.0

choice
        prompt "Spike series SOC implementation"
        depends on SOC_SERIES_RISCV_SPIKE

config SOC_RISCV_SPIKE
        bool "Spike SOC implementation"
        select ATOMIC_OPERATIONS_C

endchoice

SOC_SERIES_RISCV_SPIKEは、先程Kconfig.seriesにて定義しました。ATOMIC_OPERATIONS_Cはアトミック演算を行う関数を定義するためのコンフィグです。これを指定しないと、後ほどリンクする際にatomic_cas() がないと言われます。

アトミック演算の定義箇所

//zephyr/include/sys/atomic.h

#ifdef CONFIG_ATOMIC_OPERATIONS_BUILTIN
static inline bool atomic_cas(atomic_t *target, atomic_val_t old_value,
                          atomic_val_t new_value)
{
        return __atomic_compare_exchange_n(target, &old_value, new_value,
                                           0, __ATOMIC_SEQ_CST,
                                           __ATOMIC_SEQ_CST);
}
#elif defined(CONFIG_ATOMIC_OPERATIONS_C)
__syscall int atomic_cas(atomic_t *target, atomic_val_t old_value,
                         atomic_val_t new_value);

#else
extern int atomic_cas(atomic_t *target, atomic_val_t old_value,
                      atomic_val_t new_value);
#endif

これでもまだcmakeに怒られます。linker.ldがどうのこうのと言っています。パスもなにやらおかしいです。

Kconfig追加後のcmakeのエラー
CMake Error at ../../CMakeLists.txt:372 (message):
  Could not find linker script:
  'zephyr/soc/riscv//linker.ld'.
  Corrupted configuration?

このlinker.ldを探しているのはcmakeです。下記の部分で探しています。

cmakeがlinker.ldを探している箇所

# zephyr/CMakeLists.txt

...

if(CONFIG_HAVE_CUSTOM_LINKER_SCRIPT)
  set(LINKER_SCRIPT ${APPLICATION_SOURCE_DIR}/${CONFIG_CUSTOM_LINKER_SCRIPT})
  if(NOT EXISTS ${LINKER_SCRIPT})
    set(LINKER_SCRIPT ${CONFIG_CUSTOM_LINKER_SCRIPT})
    assert_exists(CONFIG_CUSTOM_LINKER_SCRIPT)
  endif()
else()
  # Try a board specific linker file
  set(LINKER_SCRIPT ${BOARD_DIR}/linker.ld)    # ★★★これ、もしくは★★★
  if(NOT EXISTS ${LINKER_SCRIPT})
    # If not available, try an SoC specific linker file
    set(LINKER_SCRIPT ${SOC_DIR}/${ARCH}/${SOC_PATH}/linker.ld)    # ★★★これ★★★
  endif()
endif()

if(NOT EXISTS ${LINKER_SCRIPT})
  message(FATAL_ERROR "Could not find linker script: '${LINKER_SCRIPT}'. Corrupted configuration?")
endif()

デバッグメッセージ（message(SOC_PATH ${SOC_PATH}) を書き足すなど）を出して確認すると、SOC_PATHが空になっています。まだ何か足りないようですので、調べます。SOC_PATHを定義しているのは下記の部分です。

cmakeがSOC_PATHを決める箇所

# zephyr/cmake/app/boilerplate.cmake

...

set(SOC_NAME   ${CONFIG_SOC})
set(SOC_SERIES ${CONFIG_SOC_SERIES})
set(SOC_FAMILY ${CONFIG_SOC_FAMILY})

if("${SOC_SERIES}" STREQUAL "")
  set(SOC_PATH ${SOC_NAME})
else()
  set(SOC_PATH ${SOC_FAMILY}/${SOC_SERIES})
endif()

CONFIG_SOCもしくはCONFIG_SOC_FAMILYとCONFIG_SOC_SERIESを定義する必要があるようです。探してみるとCONFIG_SOC_FAMILYはzephyr/soc/riscv/riscv-privilege/Kconfig で定義されています。

もう一方のCONFIG_SOC_SERIESはKconfig.defconfig.seriesというとても変な名前のKconfigファイルで定義するようです。

CONFIG_SOC_SERIESの定義箇所
$ cd zephyr/soc/riscv/riscv-privilege
$ grep -r 'config SOC_SERIES'

miv/Kconfig.defconfig.series:config SOC_SERIES
miv/Kconfig.series:config SOC_SERIES_RISCV32_MIV
sifive-freedom/Kconfig.defconfig.series:config SOC_SERIES
sifive-freedom/Kconfig.series:config SOC_SERIES_RISCV_SIFIVE_FREEDOM

このKconfigはどこから参照されているのでしょうか？これも一応、調べておきましょう。

Kconfig.defconfig.seriesの依存関係

# zephyr/Kconfig

  source "Kconfig.zephyr"

# zephyr/Kconfig.zephyr

  source "$(SOC_DIR)/$(ARCH)/*/Kconfig.defconfig"    # SOC_DIR = soc, ARCH = riscv


# zephyr/soc/riscv/riscv-privilege/Kconfig.defconfig

  source "soc/riscv/riscv-privilege/*/Kconfig.defconfig.series"

Kconfig.defconfig.seriesも他のSoCに習って追加しましょう。SpikeにPLICは実装されていないので、RISCV_HAS_PLICはnにしています。またFlash ROMもないので、XIP（Execution In Place）を無効にしています。

zephyr/soc/riscv/riscv-privilege/spike/Kconfig.defconfig.series

# SPDX-License-Identifier: Apache-2.0

if SOC_SERIES_RISCV_SPIKE

config SOC_SERIES
        default "spike"

config RISCV_HAS_PLIC
        default n

config NUM_IRQS
        default 16

config XIP
        default n

endif #SOC_SERIES_RISCV_SPIKE

肝心のlinker.ldを追加することも忘れないようにします。これも他のSoCを見ればわかるはず。

zephyr/soc/riscv/riscv-privilege/spike/linker.ld

/*
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @brief Linker script for the Spike series processor
 */

#include <arch/riscv/common/linker.ld>

これでKconfig周りが整ったはずです。

最後の一手はCMakeList.txt

これでクリアかと思いきや、まだcmakeに怒られます。もう一手だけ必要です。

cmake最後のエラー
CMake Error at ../../soc/riscv/riscv-privilege/CMakeLists.txt:4 (add_subdirectory):
  The source directory

    /home/katsuhiro/share/projects/oss/zephyr/soc/riscv/riscv-privilege/spike

  does not contain a CMakeLists.txt file.


-- Configuring incomplete, errors occurred!

CMakeLists.txtがないと言っています。このファイルには何を書くのが正解なのか、私もイマイチ理解できないですが、他のSoCを見ると、下記の一行を書いておけば良さそうです。

zephyr/soc/riscv/riscv-privilege/spike/CMakeLists.txt

# SPDX-License-Identifier: Apache-2.0

zephyr_sources()

ここまで変更するとcmakeのエラーが解消します。良く見ると何やらUART_CONSOLEがどうのこうのと文句を言っていますが、後ほど対応します。

Hogeボード + Spike SoCでcmake成功

$ cmake -G Ninja -DBOARD=hoge ../samples/hello_world/
-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.6", minimum required is "3.6")
-- Selected BOARD hoge
-- Loading zephyr/boards/riscv/hoge/hoge.dts as base
hoge.dts.pre.tmp:22.17-25.5: Warning (simple_bus_reg): /soc/serial: missing or empty reg/ranges property
  also defined at hoge.dts.pre.tmp:37.8-39.3
Devicetree header saved to 'zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/boards/riscv/hoge/hoge_defconfig'
Merged configuration 'zephyr/samples/hello_world/prj.conf'
Configuration saved to 'zephyr/build/zephyr/.config'
Kconfig header saved to 'zephyr/build/zephyr/include/generated/autoconf.h'

warning: UART_CONSOLE (defined at drivers/console/Kconfig:47) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL_HAS_DRIVER (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html and/or look up
UART_CONSOLE in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/katsuhiro/x-tools/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build

この後はninjaのビルドエラーがたくさん出るので、1つずつ解消していくことになります。続きはまた次回です。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月7日

link permalink link 編集する

Zephyr OSで遊ぼう その6 - 独自のSoC定義でビルド

目次: Zephyr

やっとcmakeを通過したので、いよいよビルドに挑みます。

最初のninja実行結果
In file included from ../include/arch/cpu.h:25,
                 from ../include/kernel_includes.h:34,
                 from ../include/kernel.h:17,
                 from zephyr/arch/riscv/core/offsets/offsets.c:16:
../include/arch/riscv/arch.h:25:10: fatal error: soc.h: No such file or directory
 #include <soc.h>
          ^~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

他のsoc.hを見ると、soc_common.h, devicetree.hというヘッダをインクルードしているようです。それに習っておきます。

zephyr/soc/riscv/riscv-privilege/spike/soc.h

/*
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @file SoC configuration macros for the Spike series processor
 */

#ifndef __RISCV_SPIKE_SOC_H_
#define __RISCV_SPIKE_SOC_H_

#include <soc_common.h>
#include <devicetree.h>

#endif /* __RISCV_SPIKE_SOC_H_ */

再びビルドすると、今度はPLIC_* がないと怒られます。

soc.h追加後のninja実行結果
zephyr/drivers/interrupt_controller/intc_plic.c: In function 'riscv_plic_irq_enable':
zephyr/drivers/interrupt_controller/intc_plic.c:45:41: error: 'DT_PLIC_IRQ_EN' undeclared (first use in this function); did you mean 'PLIC_IRQS'?
  volatile u32_t *en = (volatile u32_t *)DT_PLIC_IRQ_EN;
                                         ^~~~~~~~~~~~~~
                                         PLIC_IRQS

RISC-V Privileged系のSoCではPLICという割り込みコントローラのドライバが自動的に有効になります。今回、動作させるに当たってPLICのサポートは不要なので、zephyr/boards/riscv/hoge/hoge_defconfigで無効にします。具体的にはCONFIG_PLIC=nを足します。

この後cmakeからやり直してみると、

soc.h追加後のninja実行結果
zephyr/drivers/timer/riscv_machine_timer.c: In function 'set_mtimecmp':
zephyr/drivers/timer/riscv_machine_timer.c:28:31: error: 'RISCV_MTIMECMP_BASE' undeclared (first use in this function)
  volatile u32_t *r = (u32_t *)RISCV_MTIMECMP_BASE;
                               ^~~~~~~~~~~~~~~~~~~
zephyr/drivers/timer/riscv_machine_timer.c:28:31: note: each undeclared identifier is reported only once for each function it appears in
zephyr/drivers/timer/riscv_machine_timer.c: In function 'mtime':
zephyr/drivers/timer/riscv_machine_timer.c:47:31: error: 'RISCV_MTIME_BASE' undeclared (first use in this function)
  volatile u32_t *r = (u32_t *)RISCV_MTIME_BASE;
                               ^~~~~~~~~~~~~~~~
[87/94] Linking C static library zephyr/kernel/libkernel.a
ninja: build stopped: subcommand failed.

CLINTのレジスタmtime, mtimecmpのアドレスを必要としているようです。

CLINTのレジスタはどこに？

他のSoCを眺めてみると、CLINTのレジスタアドレスを定義する場所はsoc.hのようです。しかし肝心のアドレスがわかりません。QEMUのドキュメントに載っていれば簡単でしたが、見当たらなかったのでQEMUのソースコードを見ます。

QEMUのSpike, CLINT関連のソースコード

// https://github.com/qemu/qemu/blob/master/hw/riscv/spike.c

static const struct MemmapEntry {
    hwaddr base;
    hwaddr size;
} spike_memmap[] = {
    [SPIKE_MROM] =     {     0x1000,    0x11000 },
    [SPIKE_CLINT] =    {  0x2000000,    0x10000 },
    [SPIKE_DRAM] =     { 0x80000000,        0x0 },
};


// https://github.com/qemu/qemu/blob/master/include/hw/riscv/sifive_clint.h

enum {
    SIFIVE_SIP_BASE     = 0x0,
    SIFIVE_TIMECMP_BASE = 0x4000,
    SIFIVE_TIME_BASE    = 0xBFF8
};

ベースアドレスが0x02000000で、レジスタのオフセットアドレスもわかりました。soc.hに追記します。
（2/19訂正: MTIMECMP_BASEとMTIME_BASEのアドレスが逆だったので、修正しました）

zephyr/soc/riscv/riscv-privilege/spike/soc.hに追記する内容

/* Timer configuration */
#define RISCV_MTIMECMP_BASE          0x02004000
#define RISCV_MTIME_BASE             0x0200bff8

再びビルドします。やっとビルドをパスしました。

ビルド成功
$ ninja

[0/1] Re-running CMake...
-- Zephyr version: 2.1.99
-- Selected BOARD hoge
-- Loading zephyr/boards/riscv/hoge/hoge.dts as base
hoge.dts.pre.tmp:22.17-25.5: Warning (simple_bus_reg): /soc/serial: missing or empty reg/ranges property
  also defined at hoge.dts.pre.tmp:37.8-39.3
Devicetree header saved to 'zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing zephyr/Kconfig
Loaded configuration 'zephyr/build/zephyr/.config'
No change to configuration in 'zephyr/build/zephyr/.config'
No change to Kconfig header in 'zephyr/build/zephyr/include/generated/autoconf.h'
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: zephyr/build
[89/94] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
             RAM:       12752 B        16 KB     77.83%
        IDT_LIST:          25 B         2 KB      1.22%
[94/94] Linking C executable zephyr/zephyr.elf

まだめでたしめでたし、ではありません。

実行、デバッグ

生成されたバイナリを実行すると何かエラーが表示されるものの、Hello worldは表示されません。残念です。

実行しても何も表示されない
$ /usr/bin/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

qemu-system-riscv32: clint: time_hi write not implemented
qemu-system-riscv32: clint: time_lo write not implemented
qemu-system-riscv32: clint: time_hi write not implemented

このままでは全く何も実行されていないのか、惜しいところまで実行されたのか判別が付きません。以前ご紹介した（2020年1月31日の日記参照）デバッグオプション -sと -Sを使い、gdbで追跡します。

復習ですが、オプション -sはGDBの接続をlocalhost:1234で受け付け、-SはエミュレータをHalted状態で起動しgdbから再開要求をするまで動かないで待っている、という意味です。

main関数まで到達しているようだ
$ riscv64-zephyr-elf-gdb zephyr/build/zephyr/zephyr.elf

GNU gdb (crosstool-NG 1.24.0.60-a152d61) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.

...

(gdb) target remote localhost:1234

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


(gdb) b main

Breakpoint 1 at 0x800006d4: file zephyr/samples/hello_world/src/main.c, line 12.


(gdb) c

Continuing.

Breakpoint 1, main ()
    at zephyr/samples/hello_world/src/main.c:12
12              printk("Hello World! %s
", CONFIG_BOARD);

ターゲット（QEMU）に接続し、mainにブレークを設定して、実行を継続しています。Hello worldのmain関数に到達していることがわかります。素晴らしいですね。printkは呼ばれているものの、文字が出ないことが問題だとわかりました。

Hello worldを拝むには、シリアルのドライバを追加する必要があります。続きはまた次回。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月8日

link permalink link 編集する

Zephyr OSで遊ぼう その7 - 独自のシリアルドライバの枠組み

目次: Zephyr

Zephyrのビルドに成功し、gdbで追跡したところHello worldのmain関数まで到達していることもわかりました。ここまでくればあとは文字出力だけです。

まずHogeボードのdefconfigにCONFIG_UART_SPIKE=yを加えます。cmakeに「そんなコンフィグはない」と怒られるようになりますが、これから作るのでOKです。

シリアルドライバのKconfig, CMake

シリアルドライバのディレクトリはzephyr/drivers/serialにあります。ディレクトリの構造を見ると、CMakeLists.txt, Kconfig.*, ソースコードuart_*.cが並んでいます。この3つの組を追加もしくは変更すれば良さそうです。

zephyr/drivers/serial/Kconfig.spike

# SPDX-License-Identifier: Apache-2.0

menuconfig UART_SPIKE
        bool "Spike Simulator serial driver"
        depends on SOC_RISCV_SPIKE
        select SERIAL_HAS_DRIVER
        help
          This option enables the Spike Simulator serial driver.

名前は何でも良いですが、Kconfig.spikeという名前にしました。Kconfig.socとは違って、ファイルを足すだけではダメで、シリアルドライバのKconfigから読んでもらう必要があります。

zephyr/drivers/serial/Kconfigに追加する行

...

source "drivers/serial/Kconfig.litex"

source "drivers/serial/Kconfig.rtt"

source "drivers/serial/Kconfig.xlnx"

source "drivers/serial/Kconfig.spike"    # ★この行を足す★

endif # SERIAL

Kconfigを追加してcmakeをするとまだ怒られます。CMakeList.txtも変更する必要があるとのことです。

Kconfig追加後のcmake
-- Configuring done
CMake Error at ../../cmake/extensions.cmake:372 (add_library):
  No SOURCES given to target: drivers__serial
Call Stack (most recent call first):
  ../../cmake/extensions.cmake:349 (zephyr_library_named)
  ../../drivers/serial/CMakeLists.txt:3 (zephyr_library)


CMake Generate step failed.  Build files cannot be regenerated correctly.
FAILED: build.ninja

CMakeLists.txtは他の行に習って追加します。CMakeLists.txtを変更しただけだとuart_spike.cが無いと言われるので、touch uart_spike.cで空のファイルを作成します。

zephyr/drivers/serial/CMakeLists.txtに追加する行

...

zephyr_library_sources_if_kconfig(uart_liteuart.c)
zephyr_library_sources_ifdef(CONFIG_UART_RTT_DRIVER uart_rtt.c)
zephyr_library_sources_if_kconfig(uart_xlnx_ps.c)
zephyr_library_sources_if_kconfig(uart_spike.c)    # ★この行を足す★

...

他の行に習って追加するだけではつまらないので、CMakeのスクリプトも眺めます。今回使用したzephyr_library_sources_if_kconfig() とzephyr_library_sources_ifdef() との違いは、ソースコードのコメントにある説明がわかりやすいです。

ファイル名を大文字にして、CONFIG_ と連結させた名前（今回のケースだとCONFIG_UART_SPIKE）を生成して、コンフィグが有効ならソースコードをビルド対象に加えるという意味です。Kconfigのコンフィグはy, n, mの3値を取りますが、Zephyrのスクリプトでは、コンフィグが有効だとyという値が入り、無効だと未定義になるようです。

zephyr_library_sources_if_kconfigの実装

# zephyr/cmake/extensions.cmake

...

# zephyr_library_sources_if_kconfig(fft.c)
# is the same as
# zephyr_library_sources_ifdef(CONFIG_FFT fft.c)

...

function(zephyr_library_sources_if_kconfig item)
  get_filename_component(item_basename ${item} NAME_WE)
  string(TOUPPER CONFIG_${item_basename} UPPER_CASE_CONFIG)
  zephyr_library_sources_ifdef(${UPPER_CASE_CONFIG} ${item})
endfunction()

...

function(zephyr_library_sources_ifdef feature_toggle source)
  if(${${feature_toggle}})
    zephyr_library_sources(${source} ${ARGN})
  endif()
endfunction()


# zephyr/cmake/extensions.cmake

...

function(zephyr_library_sources source)
  target_sources(${ZEPHYR_CURRENT_LIBRARY} PRIVATE ${source} ${ARGN})
endfunction()

...

以上の変更でビルドが通り、シリアルドライバを実装する枠が完成しました。続きは次回。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月9日

link permalink link 編集する

Zephyr OSで遊ぼう その8 - 独自のシリアルドライバの実装

目次: Zephyr

前回はシリアルドライバの枠組み、というか、何も実装されていないドライバを追加しました。今回はシリアルドライバを実装します。

Zephyrのドライバについてはドキュメント（Device Driver Model - Zephyr Project Documentation）があります。ドライバの定義や初期化を司るAPIがDriver APIの節に書いてあります。

今回作成するUARTドライバでは初期化は要りませんが、ドライバのAPIをいくつか実装したいのでDEVICE_AND_API_INIT() を使います。

UARTのドライバで実装できるAPIの一覧はドキュメント（UART - Zephyr Project Documentation）に書いてあります。APIはたくさんありますが、poll_in, poll_outがあれば動作するようなので、この2つを作ります。

コードは下記のようにしました。

QEMU Spikeモード用のシリアルドライバ実装

/*
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * @brief UART driver for the Spike Simulator
 */

#include <kernel.h>
#include <arch/cpu.h>
#include <drivers/uart.h>

volatile u64_t tohost;
volatile u64_t fromhost;

void uart_spike_poll_out(struct device *dev, unsigned char c)
{
        u64_t cmd;

        // QEMU spike mode
        u8_t dev_no = 1;
        u8_t cmd_no = 1;
        u64_t payload = c;

        cmd = ((u64_t)dev_no << 56) |
                ((u64_t)cmd_no << 48) |
                (payload & 0xffffffffffffULL);

        tohost = cmd;

        while (fromhost == 0)
                ;
        fromhost = 0;
}

static int uart_spike_poll_in(struct device *dev, unsigned char *c)
{
        return -1;
}

static int uart_spike_init(struct device *dev)
{
        return 0;
}

static const struct uart_driver_api uart_spike_driver_api = {
        .poll_in          = uart_spike_poll_in,
        .poll_out         = uart_spike_poll_out,
};

DEVICE_AND_API_INIT(uart_spike_0, DT_INST_0_SPIKE_UART_SPIKE_LABEL,
                    uart_spike_init, NULL, NULL,
                    PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_DEVICE,
                    (void *)&uart_spike_driver_api);

このままビルドするとDEVICE_AND_API_INIT() に渡しているラベルDT_INST_0_SPIKE_UART_SPIKE_LABELが未定義だと怒られます。これについては後ほど作り方を説明します。

ラベルが未定義のエラー
zephyr/drivers/serial/uart_spike.c:73:35: error: 'DT_INST_0_SPIKE_UART_SPIKE_LABEL' undeclared here (not in a function); did you mean 'DT_COMPAT_SPIKE_UART_SPIKE'?
 DEVICE_AND_API_INIT(uart_spike_0, DT_INST_0_SPIKE_UART_SPIKE_LABEL,
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/device.h:106:11: note: in definition of macro 'DEVICE_AND_API_INIT'
   .name = drv_name, .init = (init_fn),     \
           ^~~~~~~~
[89/97] Linking C static library zephyr/libzephyr.a
ninja: build stopped: subcommand failed.

初期化はDEVICE_AND_API_INIT() で指定します。引数の意味は DEVICE_AND_API_INIT() のドキュメントを見たほうが良いでしょう。

引っかかりそうなところはdev_nameにダブルクォートを「付けない」こと、一番に初期化されるようにPRE_KERNEL_1にすることくらいでしょうか。

QEMU Spikeモードの文字出力

文字出力poll_outの実装は、グローバル変数に謎の数字を書くだけの不思議実装になっていますが、これはQEMU SpikeモードのHost, Guest間インタフェースの仕様に従っているためです。

ちなみにQEMU側はこんなコードになっています。

QEMU Spikeモードの文字出力

// https://github.com/qemu/qemu/blob/master/hw/riscv/riscv_htif.c

...

static void htif_handle_tohost_write(HTIFState *htifstate, uint64_t val_written)
{
    uint8_t device = val_written >> 56;
    uint8_t cmd = val_written >> 48;
    uint64_t payload = val_written & 0xFFFFFFFFFFFFULL;
    int resp = 0;

...

    } else if (likely(device == 0x1)) {
        /* HTIF Console */
        if (cmd == 0x0) {
            /* this should be a queue, but not yet implemented as such */
            htifstate->pending_read = val_written;
            htifstate->env->mtohost = 0; /* clear to indicate we read */
            return;
        } else if (cmd == 0x1) {
            qemu_chr_fe_write(&htifstate->chr, (uint8_t *)&payload, 1);
            resp = 0x100 | (uint8_t)payload;
        } else {
            qemu_log("HTIF device %d: unknown command\n", device);
        }
    } else {

...

    htifstate->env->mfromhost = (val_written >> 48 << 48) | (resp << 16 >> 16);
    htifstate->env->mtohost = 0; /* clear to indicate we read */
}

途中のif文を見るとわかるように、device=1, cmd=1にすると文字が出力できます。またQEMUが文字出力を終えたときにfromhostが0以外の値に書き換わります（なので、Zephyrのシリアルドライバ側ではfromhostをポーリングで監視する実装にしています）。

シリアルドライバのラベル定義とbindings

DT_INST_0_SPIKE_UART_SPIKE_LABELのようなラベルはユーザが定義するのではなく、zephyr/dts/bindings以下のファイルに存在するcompatibleと、デバイスツリーを突き合わせて自動生成するみたいです。命名規則については、以前Zephyr OSで遊ぼう その3（2020年2月4日の日記参照）で紹介したとおりです。

zephyr/dts/bindings/serial/spike,uart-spike.yaml

# SPDX-License-Identifier: Apache-2.0

description: UART for Spike Simulator

compatible: "spike,uart-spike"

include: uart-controller.yaml

デバイスツリーのcompatibleの突き合わせとラベルの自動生成は、zephyr/scripts/dts/gen_defines.pyとedtlib.py辺りでやっていることは間違いなさそうなのですが、詳細な仕組みはまだ追えていません。

若干もやっとしますがYAMLファイルを作成して、compatibleをデバイスツリーで使用したものと合わせると、目的のラベルDT_INST_0_SPIKE_UART_SPIKE_LABELが定義され、ビルドが通ります。

Hello world

ビルドが通ったら実行します。

QEMU SpikeモードでHello world
$ /usr/bin/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

qemu-system-riscv32: clint: time_hi write not implemented
qemu-system-riscv32: clint: time_lo write not implemented
qemu-system-riscv32: clint: time_hi write not implemented
*** Booting Zephyr OS build zephyr-v2.1.0-1699-gbb40304f2531  ***
Hello World! hoge

やっとHello worldが拝めました。長かった。 （2/19追記: qemu-system-riscv32: clint: time_hi write not implementedのエラーメッセージはmtimeとmtimecmpのアドレスが逆だったために発生していたエラーです。アドレス修正後は表示されません）

パッチ

今まで説明してきた変更をパッチとしてまとめておきます。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月10日

link permalink link 編集する

Zephyr OSで遊ぼう その9 - Zephyr 2.2.0に対応する

目次: Zephyr

Zephyrは開発中なので、ときおり内部構造が変わり、過去と互換性がなくなってしまうことがあります。ボードやSoCの定義も例外ではありません。

前回までの説明ではZephyr 2.1.0を使用していましたが、2.1.0から2.2.0の間で、ボードのdefconfigの書き方が変更されました。具体的に言うと、

  • ボード側: アーキテクチャCONFIG_RISCVを書かなくて良くなった
  • SoC側: CONFIG_RISCVをdepends on → selectに変える必要が生じた

下記のパッチにあるような変更をすると、2.2.0でもHogeボードとSpike SoCの対応が適用できます。

それぞれ1行ずつしか変更していませんので、すぐわかると思います。

Zephyrの不思議なコンフィグ

ZephyrはLinuxと同じKconfigを採用していますが、コンフィグの起点に対する考え方がだいぶ違います。Zephyrは最初にcmakeで「ボード名（-DBOARDオプション）」を指定します。すなわちコンフィグの起点はボードです。一方のLinuxはexport ARCH=x86のようにアーキテクチャを設定の起点にします。

Zephyr 2.1.0では、アーキテクチャ（CONFIG_RISCVなど）、SoC（CONFIG_SOC_RISCV_SIFIVE_FREEDOMなど）、ボードの依存関係は下記のようになっていました。

2.1.0の依存関係
アーキテクチャ（ボードのdefconfigがyにする）← アーキテクチャが依存の起点
↑depends on
SoC（ボードのdefconfigがyにする）
↑depends on
ボード（ボードのdefconfigがyにする）← Zephyrはなぜかボードがコンフィグの起点

依存関係とコンフィグの起点が矛盾しているためmenuconfigが異常な動きをします。おそらくninja menuconfigを弄れば矛盾に気づくと思いますが、Zephyrはなぜかボードが未対応のアーキテクチャやSoC（例えばqemu_riscv32でCONFIG_ARMを選択できる）を有効にできます。Zephyr 2.1.0だと2つ、おかしな設定ができます。

  • qemu_riscv32ボードで未対応のアーキテクチャ（例えばCONFIG_X86）を選択すると、SoCの選択肢がおかしくなる（X86だと言っているのに、RISC-V用のSoCが出てくる）
  • qemu_riscv32ボードで未対応のSoC（例えばCONFIG_SOC_LITEX_VEXRISCV）を選択すると、ボードの一覧が空になって選べなくなる（これは2.2.0でもできる）

実際にninja menuconfigで、qemu_riscv32が未対応のアーキテクチャを選ぶと下記のようになります。

Zephyr 2.1.0の変なコンフィグ
# qemu_riscv32のデフォルト

    Modules  --->
    Board Selection (QEMU RISCV32 target)  --->
    Board Options  ----
    SoC/CPU/Configuration Selection (SiFive Freedom SOC implementation)  --->
    Hardware Configuration  --->
    RISCV Options  --->
    Architecture (RISCV architecture)  --->
    General Architecture Options  --->
    General Kernel Options  --->
    ...


# ボードが対応していないアーキテクチャを選択すると、SoCが勝手に変わる、ボードは何も選べなくなる

    Modules  --->
    Board Selection  ----
    Board Options  ----
    SoC/CPU/Configuration Selection (LiteX VexRiscv system implementation)  --->    ★なぜかRISC-V用のSoCが出てくる
    Hardware Configuration  ----
    Architecture (x86 architecture)  --->    ★x86に変えた
    General Architecture Options  --->
    General Kernel Options  --->
    ...

そもそもx86が選択可能な時点でおかしいですが、x86を選択したのにx86じゃないSoCが選択肢に出てくるなど、かなりおかしな動きです。

中途半端に直ったZephyr 2.2.0

Zephyr 2.2.0では依存関係は下記のように、少しだけ整理されました。

2.2.0の依存関係
アーキテクチャ（SoCが強制的にyにする、menuconfigでは触れない）
↑select
SoC（ボードのdefconfigがyにする）
↑depends on
ボード（ボードのdefconfigがyにする）← ここが起点

アーキテクチャを変えることが出来なくなりました。前よりマシですが、やはり変なところは残っていて、未対応のSoCを選択するとボードの選択肢が消えてしまいます。

Zephyr 2.2.0の変なコンフィグ設定
# qemu_riscv32のデフォルト

    Modules  --->
    Board Selection (QEMU RISCV32 target)  --->
    Board Options  ----
    SoC/CPU/Configuration Selection (SiFive Freedom SOC implementation)  --->
    Hardware Configuration  --->
    RISCV Options  --->
    ...


# SoCを無理やり未対応のものに変えると、ボードが選べなくなる

    Modules  --->
    Board Selection  ----
    Board Options  ----
    SoC/CPU/Configuration Selection (LiteX VexRiscv system implementation)  --->
    Hardware Configuration  ----
    RISCV Options  --->
    ...

個人的にはZephyrのKconfigの使い方は変だな、と思います。依存関係があることはわかっているのだから、依存の根本の方から設定（要は、アーキテクチャ → SoC → ボード、の順）したら良いのに、Zephyrはなぜかボードの設定から固定していて、変な動きになっています。

Linuxはどうしているかというと、最初にexport ARCH=x86とします。すなわち、アーキテクチャを設定の起点にしています。自然です。特に変な動きもしません。

Zephyrの方がLinuxより後発ですが、ビルド周りは退化したように感じます。不思議。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月16日

link permalink link 編集する

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言語の世界です。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月17日

link permalink link 編集する

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のソースコード上には存在しないように見えます。これは一体何者なんでしょう？

続きはまた今度。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月18日

link permalink link 編集する

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に含まれるようになるんでしょう？

続きはまた今度。

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

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月19日

link permalink link 編集する

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)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月20日

link permalink link 編集する

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)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月21日

link permalink link 編集する

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)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


2020年2月22日

link permalink link 編集する

Zephyr - まとめリンク

目次: Zephyr

導入、ブート周り

ボード、ドライバなど

SMP対応編

浮動小数点数命令など

その他

編集者:すずき(2024/08/05 11:55)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする


こんてんつ

日記の全文検索

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 2025年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)

This is Simple Diary 1.0  Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.3.8.  using GD bundled (2.1.0 compatible)(png support.)