意外发现有awboot能够代替uboot直接引导内核，体验了一下果断选择awboot，因为足够简洁，编译大小只有32k，和uboot接近1M的体量相比，简直是小而美，启动速度也比uboot快上不少，也能同时支持sd卡，spinand，spinorflash启动。
GitHub - szemzoa/awboot: small linux bootloader for Allwinner T113-S3small linux bootloader for Allwinner T113-S3. Contribute to szemzoa/awboot development by creating an account on GitHub.https://github.com/szemzoa/awboot

说起uboot不禁想起几年前路由器第三方固件盛行的时期，那时的路由器还没有很复杂的方案，第三方固件往往比官方固件更易用功能更丰富，买个普通路由器换颗flash，内存芯片刷个系统就能获得更丰富的功能体验，各种固件openwrt，Padavan，高格百花齐放，为了刷机方便，系统的uboot都要支持tftp，串口甚至web的文件传输接口，由此孕育而出了大名鼎鼎的Breed，仅仅为了更新固件更方便，不用spi flash编程器那么麻烦的烧写。而到了全志嵌入式这边，由于自带usb接口的BROM，使用sunxi-fel或者xfel烧写flash已足够方便，所以使用uboot更新固件的需求就不是那么大，况且全志的方案比路由器的方案定制性更高一些，没有通用的第三方固件可以刷，所以uboot的功能就完全成了摆设，让用户使用sunxi-fel更新固件都要比uboot更新固件更稳定更实用，消费者用户用不到，开发人员也不会去用，那uboot的1m大小，集成的各种usb，网络，屏幕驱动，环境变量，文件系统，设备树编辑等功能就显得格外多余。

awboot相比spl+uboot的区别就是少了一次跳转的过程，由BROM拉起的boot0拥有足足160kb的sram，足够编写执行引导kernel的代码，所以这何尝不是一种恰到好处。

传统spl+uboot启动流程

过程	实现(提供)	Code位置	变量内存空间
BROM	全志官方编写，固化在cpu中	BROM(0x00-48k)	SRAM
boot0	spl(<32k)	SRAM(0x20000-32k)	SRAM(0x20000-32k)
uboot	uboot(200k-1M)	DRAM(0x40000000-128M)	DRAM(0x40000000-128M)
kernel	Linux(3M-5M)	DRAM(0x40000000-128M)	DRAM(0x40000000-128M)

awboot启动流程

过程	实现(提供)	Code位置	变量内存空间
BROM	全志官方编写，固化在cpu中	BROM(0x00-48k)	SRAM
boot0	awboot(<128k)	SRAM(0x20000-128k)	SRAM(0x20000-160k)
kernel	Linux(3M-5M)	DRAM(0x40000000-128M)	DRAM(0x40000000-128M)

下面是awboot的编译过程：
修改makefile中的CROSS_COMPILE编译器定义为arm-none-linux-gnueabihf，或者使用

make CROSS_COMPILE=arm-none-linux-gnueabihf

命令编译
如果不是git拉取的而是手动下载解压的源码，需要去除git编译目标，位于makefile line:49
出现DWORD重复定义的错误，删除lib\fatfs\integer.h中的DWORD定义
链接出现未定义函数__aeabi_unwind_cpp_pr0，makefile中添加编译选项CFLAGS += -lgcc_eh
链接出现未定义函数raise，在main.c中添加函数

int raise(void)
{
	return 0;
}

编译成功，出现awboot.bin等文件