全志D1芯片的启动流程最底层分析

关于d1哪吒开发板的启动流程分析

1.本文概述

2.D1上电后启动的第一个程序

3.启动SPL

4.启动opensbi

5.裸机程序的编写

6.小结

1.本文概述

从RISCV生态的角度上来看，D1哪吒开发板确实是一块不错的可以研究很深的开发板。本文主要从研究D1启动流程的角度出发，探索一下D1的裸机开发实践。对于研究D1的底层裸机开发，首先需要知道可以玩那些东西，也可以对RISCV相关的软件生态有比较透彻的理解，本文会从spl阶段到opensbi阶段以及后续阶段做一个简单的分析。

2.D1上电后启动的第一个程序

D1上电后，首先启动一个（Boot ROM）BROM。根据芯片手册的描述，该BROM的启动地址是0地址处开始启动。

一共是48KB的内存空间用于运行BROM，那么这个BROM做了哪些事情？首先它根据efuse和GPIO选择了启动的媒体类型。支持的启动方式有

SD card

eMMC

SPI NOR Flash

SPI NAND Flash

并且可以根据GPIO的选择和Efuse的选择决定启动的模式。同时也支持USB的启动方式，这就为fel启动方式做了很好铺垫。

总的说来，BROM就是从其他的介质中读取SPL，然后放到SRAM中执行，同时也通过FEL运行环境。

3.启动SPL

当BROM启动完成后，接下来要去存储介质中寻找SPL的程序，这部分可以通过对全志D1 SDK的源代码进行查看。

不难看出，在tina-d1-open的源代码下有lichee的代码。另外brandy-2.0下有spl、opensbi和u-boot的代码。通过对spl代码的研究，主要从流程上可以知道，spl的代码运行在sram中。

通过查看，可以看到SRAM为32KB，但是实际编译出来的估计大小在32KB~64KB，远大于32KB，这样怀疑的可能性是SRAM可能大于32KB或者利用了DSP0 IRAM的空间。在编译的过程中，发现SPL的固件的头部一段区域，也就是0x00020000地址开始处的一段空间，是初始化的参数，SPL可以根据这个参数选择初始化的串口编号，初始化的DDR参数等等。在这里面编译的串口并非开发板的参数的串口参数，后面在制作固件的时候，会将头部的信息替换。为此我做了一个专门研究D1 哪吒裸机的仓库，来研究其实际的启动信息。

首先下载平头哥的交叉编译工具链。

然后通过设置

export PATH=/yourpath/：$PATH

将gcc的路径添加到环境变量，直接在spl目录下编译即可。

编译后会在nboot的目录下生成相关的固件。

在生成的固件中，每个固件分别表示从哪种介质中启动下一阶段。前面说过，spl的头部存放了一些初始化的参数变量，所以我直接通过一个脚本make_download.sh将spl的头部一些信息替换了。这样下来，就能够正常的启动spl阶段了，并且可以正常的初始化DDR。按下开发板的FEL键并且上电。

下载可以利用tools/windows目录下的xfel工具进行下载。

可以正常的启动SPL。xfel的工具是xboot大佬旨在打造全志裸机的万能开发工具，感觉用起来还是挺好。

当前xfel在d1上支持了ddr初始化，下载到SRAM和DDR3等操作，并支持运行程序。非常的强大，后面做裸机开发会经常用到，后续如果能够支持USB烧录SPI NAND Flash，那会更加的好用。那么在spl里做了哪些事情？首先SPL是运行在SRAM中的程序，这段程序受到SRAM尺寸大小的影响，并不会做的很复杂。主要功能来说：

1.通过引脚判断是否启动JTAG

2.初始化DDR

3.使能MMU

4.根据SD CARD、SPI NAND FLASH 、SPI NOR FLASH判断初始化那种外设。

5.根据opensbi/rtos/uboot，将其搬运到DDR中执行，然后程序运行在DDR中。

4.启动opensbi

此时程序就运行在DDR中了，对于开发RISCV的人来说，opensbi并不陌生，一方面这个是后台常驻程序，提供S-mode和M-mode的转换层，另外也起到引导下一阶段程序的目的。这个d1下个阶段指的是uboot。然后opensbi就常驻在M-mode下了。作为独立的程序，我也在裸机层面去编译下载opensbi。

https://github.com/bigmagic123/d1-nezha-baremeta/tree/main/opensbi

编译的过程可以通过

要想在d1上运行opensbi，首先需要根据下面的情况进行编译。

cd d1-nezha-baremeta/opensbi

然后导入环境变量

export CROSS_COMPILE=/home/bigmagic/work/toolchain-thead-glibc/riscv64-glibc-gcc-thead_20200702/bin/riscv64-unknown-linux-gnu- PLATFORM_RISCV_ISA=rv64gcxthead FW_JUMP_ADDR=0x40200000 FW_TEXT_START=0x40000000

最后进行编译

make PLATFORM=thead/c910

正常情况下，生成

AS platform/thead/c910/standby-normal/standby.o

CC platform/thead/c910/standby-normal/loadelf.o

CC platform/thead/c910/sunxi_platform.o

CC platform/thead/c910/opensbi_head.o

AS platform/thead/c910/sunxi_cpuidle.o

CC platform/thead/c910/sunxi_idle.o

AR platform/thead/c910/lib/libplatsbi.a

AS platform/thead/c910/firmware/fw_dynamic.o

ELF platform/thead/c910/firmware/fw_dynamic.elf

OBJCOPY platform/thead/c910/firmware/fw_dynamic.bin

AS platform/thead/c910/firmware/fw_jump.o

ELF platform/thead/c910/firmware/fw_jump.elf

OBJCOPY platform/thead/c910/firmware/fw_jump.bin

可以把build/platform/thead/c910/firmware/fw_jump.bin文件下载。

可以通过下面的三条指令进行下载

.xfel.exe ddr ddr3

.xfel.exe write 0x40000000 fw_jump.bin

.xfel.exe exec 0x40000000

最后可以看到启动如下

其中对opensbi的下载流程，实际上这里直接是通过xfel初始化ddr，然后将程序加载到ddr中直接启动运行。并没有通过spl阶段，如果想要自己编译的程序通过spl --》 opensbi。可以在Linux上通过dd命令将程序烧录到sd卡中。

这里将boot0的固件烧录到sd卡的8K处，系统可以正常的启动。

5.裸机程序的编写

在分析了上述SPL和opensbi的启动流程后，自行编译一个简单的裸机程序就容易许多。从启动流程的角度上来说，只需要实现初始化时钟、串口即可。这样就能够享受D1上裸机开发的乐趣了。更多的外设扩展需要根据芯片手册去进行编程。

https://github.com/bigmagic123/d1-nezha-baremeta/tree/main/src/1.startup

而烧录的流程，可以利用xfel初始化ddr，然后烧录到ddr中，这样方便调试。目前裸机开发代码比较好的可以参考xboot的代码。

https://github.com/xboot/xboot/tree/test-d1

xboot的底层也会用到基本的裸机编程部分的代码实现，也是非常值得研究和学习的。

6.小结

全志D1芯片的启动流程最底层的分析来看，和其他全志产品线的芯片的启动流程基本类似，主要需要理解的是fel模式下对SRAM，DDR等操作，这样在做裸机开发的时候，才能将程序下载进去。有了这些理解，在做riscv的底层编程的时候，才能透彻的理解其启动的流程和原理。

原文标题：关于d1哪吒开发板的启动流程分析

文章出处：【微信公众号：嵌入式IoT】欢迎添加关注！文章转载请注明出处。

责任编辑：haq