3 Apr
2022
3 Apr
'22
2:15 a.m.
On Tue, Mar 22, 2022 at 04:59:19PM -0400, Sean Anderson wrote:
This adds a boot method for loading the next stage from the host. It is mostly modeled off of spl_load_image_ext. I am not really sure why/how spl_load_image_fat uses three different methods to load the image, but the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol. While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot. Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of lines of TCL) and then loading U-Boot. The DDR initialization typically uses hard-coded register writes, and is not easily adapted to different boards. BOOT_DEVICE_SMH allows booting with SPL, leveraging U-Boot's existing DDR initialization code. This is the method used by NXP's CodeWarrior IDE on Layerscape processors (see AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and then loading U-Boot. This is tricky, because the debugger must stop the boot after the bootloader has completed its work. Trying to load U-Boot too early can cause failure to boot. This is the method used by Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the image to load U-Boot at the appropriate place. This can be a bit tricky, because the load address is dependent on the header size. An elf with symbols must also be used in order to stop at the appropriate point. BOOT_DEVICE_SMH can be viewed as an extension of this process, where SPL automatically stops and tells the host where to place the image.
Signed-off-by: Sean Anderson sean.anderson@seco.com
Applied to u-boot/next, thanks!
--
Tom