mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-25 06:00:43 +00:00
8e1c9fe243
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> |
||
---|---|---|
.. | ||
arc | ||
arm | ||
m68k | ||
microblaze | ||
mips | ||
nds32 | ||
nios2 | ||
powerpc | ||
riscv | ||
sandbox | ||
sh | ||
x86 | ||
xtensa | ||
.gitignore | ||
Kconfig | ||
u-boot-elf.lds |