关于d1哪吒开发板的启动流程分析
原稿来自公众号：嵌入式IoT
原创：bigmagic
链接：关于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 哪吒裸机的仓库，来研究其实际的启动信息。
https://github.com/bigmagic123/d1-nezha-baremeta
首先下载平头哥的交叉编译工具链。
链接：https://pan.baidu.com/s/1Mpfv_6BlarLSVZcgs548HQ
提取码：mipy
然后通过设置
export PATH=/yourpath/:$PATH
将gcc的路径添加到环境变量，直接在spl目录下编译即可。
编译后会在nboot的目录下生成相关的固件。
在生成的固件中，每个固件分别表示从哪种介质中启动下一阶段。前面说过，spl的头部存放了一些初始化的参数变量，所以我直接通过一个脚本make_download.sh将spl的头部一些信息替换了。这样下来，就能够正常的启动spl阶段了，并且可以正常的初始化DDR。按下开发板的FEL键并且上电。
下载可以利用tools/windows目录下的xfel工具进行下载。
xfel.exe write 0x20000 boot0_sdcard_sun20iw1p1.bin
xfel.exe exec 0x20000
可以正常的启动SPL。xfel的工具是xboot大佬旨在打造全志裸机的万能开发工具，感觉用起来还是挺好。
https://github.com/xboot/xfel
当前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的底层编程的时候，才能透彻的理解其启动的流程和原理。
