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.ander...@seco.com>
Applied to u-boot/next, thanks! -- Tom
signature.asc
Description: PGP signature