全志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

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分