非教程，仅记录操作流程与思路，以供参考。
Day 1
目的是从0开始，一级一级构建启动所需的固件，直到加载内核进入系统。因而选择不使用SDK一步完成所有步骤构建，而是逐级构建，手动引导启动。
参考文档: Overview
根据文档描述，SoC片上固化的BootROM是第一级引导程序，能够将第二级引导加载到SRAM，而SDK的实现则是将UBoot SPL作为二级引导交给BootROM启动。
决定启动模式的bootstrap pin有两个，但是似乎只有2/4的case是被BootROM识别的（即：从UART XMODEM或SPI NOR FLASH）。待验证
接UART到电脑，minicom 115200连接至UART针脚：
上电，看到了输出：
Welcome to minicom 2.8
OPTIONS: I18n
Port /dev/ttyACM0, 16:32:33
Press CTRL-A Z for help on special keys
(C)StarFive
CCC
(C)StarFive
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
接下来研究如何构建UBoot SPL。
从SDK入手开始研究。阅读Makefile可知构建SPL的目标为spl_bin_normal_out，涉及先构建UBoot再对SPL使用spl_tool做header两步。
首先构建Uboot。继续追踪Makefile目标：all -> uboot_fit -> (sbi_bin, uboot_its_file, uboot)
sbi暂且不管，先看看uboot_its_file是什么东西。追进去发现是UBoot FIT的uImage相关的构建描述。参考：Flattened uImage Tree (FIT) Images – The Good Penguin
再去追uboot本身的构建：uboot := $(uboot_wrkdir)/u-boot.bin, $(uboot): $(uboot_srcdir) $(target_gcc)锁定了构建时执行的命令与环境。
整个构建流程使用的是buildroot体系下构建的交叉编译工具链。我先试试ubuntu软件包中的rv64gc编译器能不能用。
首先将uboot源码拖到本地。我直接选择使用最新源码，而非sdk指定的commit
git clone git@github.com:starfive-tech/u-boot.git
再创建构建目录，执行out of tree build：
mkdir -p build/u-boot
make -C u-boot O=$(pwd)/build/u-boot CROSS_COMPILE=riscv64-linux-gnu- starfive_visionfive2_defconfig
也可以顺手看一眼menuconfig：make -C u-boot O=$(pwd)/build/u-boot CROSS_COMPILE=riscv64-linux-gnu- menuconfig
加上并行开始编译：make -C u-boot O=$(pwd)/build/u-boot CROSS_COMPILE=riscv64-linux-gnu- -j12
挺顺畅就完成了，只有一些小warning。
再解决spl_bin_normal_out的另一个依赖spl_tool
git clone git@github.com:starfive-tech/Tools.git
pushd Tools/spl_tool
make
popd
最后用这个工具处理之前编译uboot时产生的spl：
./Tools/spl_tool/spl_tool -c -f build/u-boot/spl/u-boot-spl.bin
接下来查看如何使用UART启动模式加载这个固件。参考：GitHub - starfive-tech/Tools
直接在之前开启的minicom中摁下CTRL+A再摁S，上下选择xmodem，选择生成的u-boot-spl.bin.normal.out，Okay。
成功看到了SPL执行输出：
U-Boot SPL 2021.10 (Jan 27 2024 - 17:52:34 +0800)
LPDDR4: 4G version: g8ad50857.
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
盲猜是因为调整bootstrap pin为串口启动，导致SPL内的判断逻辑异常。这次尝试上电后先重新配置bootstrap pin为SPI FLASH，再xmodem上传SPL。
U-Boot SPL 2021.10 (Jan 27 2024 - 17:52:34 +0800)
LPDDR4: 4G version: g8ad50857.
Trying to boot from SPI
OpenSBI v1.2
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : StarFive VisionFive V2
Platform Features : medeleg
Platform HART Count : 5
Platform IPI Device : aclint-mswi
看来是成功使用串口上传的SPL引导了FLASH上的OpenSBI。再对比一下直接以FLASH模式上电：
U-Boot SPL 2021.10 (Feb 28 2023 - 21:44:53 +0800)
DDR version: dc2e84f0.
Trying to boot from SPI
OpenSBI v1.2
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : StarFive VisionFive V2
Platform Features : medeleg
Platform HART Count : 5
Platform IPI Device : aclint-mswi
Platform Timer Device : aclint-mtimer @ 4000000Hz
可以确定使用的SPL是编译的新版本
去确认了下upstream状态，visionfive2的支持似乎已经完全合入上游了，那就试试主线uboot的spl是什么情况。
U-Boot SPL 2024.01-01078-ge7f9e5eb58 (Jan 27 2024 - 18:41:35 +0800)
DDR version: dc2e84f0.
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
可以，很爽的体验，有upstream support实在是太舒适了。甚至还集成了打包opensbi（当然我还没构建，这块就报错了）
https://rvspace.org/en/project/JH7110_Upstream_Plan
看来接下来处理opensbi的时候也可以直接使用上游仓库了。包括官方SDK在内的这些老仓库可以认为是过时的了。上游uboot的文档里已经提供了构建fit的方法，甚至还有emmc/sd部署方法，可以跳过NOR FLASH需求…?