2018-05-06 17:58:06 -04:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2012-08-14 08:50:58 -07:00
|
|
|
/*
|
|
|
|
|
* (C) Copyright 2012
|
|
|
|
|
* Texas Instruments, <www.ti.com>
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _ASM_SPL_H_
|
|
|
|
|
#define _ASM_SPL_H_
|
|
|
|
|
|
2022-06-10 22:59:33 -04:00
|
|
|
#if defined(CONFIG_ARCH_EXYNOS4) || defined(CONFIG_ARCH_EXYNOS5) || \
|
|
|
|
|
defined(CONFIG_ARCH_K3) || defined(CONFIG_ARCH_OMAP2PLUS)
|
2012-08-14 08:50:58 -07:00
|
|
|
/* Platform-specific defines */
|
|
|
|
|
#include <asm/arch/spl.h>
|
|
|
|
|
|
2014-04-23 21:20:43 +09:00
|
|
|
#else
|
|
|
|
|
enum {
|
|
|
|
|
BOOT_DEVICE_RAM,
|
|
|
|
|
BOOT_DEVICE_MMC1,
|
|
|
|
|
BOOT_DEVICE_MMC2,
|
|
|
|
|
BOOT_DEVICE_MMC2_2,
|
|
|
|
|
BOOT_DEVICE_NAND,
|
|
|
|
|
BOOT_DEVICE_ONENAND,
|
|
|
|
|
BOOT_DEVICE_NOR,
|
|
|
|
|
BOOT_DEVICE_UART,
|
|
|
|
|
BOOT_DEVICE_SPI,
|
2016-02-02 19:12:31 +09:00
|
|
|
BOOT_DEVICE_USB,
|
2014-04-23 21:20:43 +09:00
|
|
|
BOOT_DEVICE_SATA,
|
|
|
|
|
BOOT_DEVICE_I2C,
|
2015-02-07 10:47:29 -07:00
|
|
|
BOOT_DEVICE_BOARD,
|
2016-08-30 15:38:57 +02:00
|
|
|
BOOT_DEVICE_DFU,
|
2017-05-28 12:55:11 -07:00
|
|
|
BOOT_DEVICE_XIP,
|
2017-06-22 23:38:36 +02:00
|
|
|
BOOT_DEVICE_BOOTROM,
|
spl: Add semihosting boot method
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>
2022-03-22 16:59:19 -04:00
|
|
|
BOOT_DEVICE_SMH,
|
2014-04-23 21:20:43 +09:00
|
|
|
BOOT_DEVICE_NONE
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-03-03 08:02:58 -07:00
|
|
|
#ifndef CONFIG_DM
|
2012-08-22 15:31:05 -07:00
|
|
|
extern gd_t gdata;
|
2015-03-03 08:02:58 -07:00
|
|
|
#endif
|
2012-08-22 15:31:05 -07:00
|
|
|
|
2012-08-14 08:50:58 -07:00
|
|
|
#endif
|
