2018-05-06 21:58:06 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2012-08-14 15:50:58 +00:00
|
|
|
/*
|
|
|
|
|
* (C) Copyright 2012
|
|
|
|
|
* Texas Instruments, <www.ti.com>
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _ASM_SPL_H_
|
|
|
|
|
#define _ASM_SPL_H_
|
|
|
|
|
|
2017-05-13 02:33:16 +00:00
|
|
|
#if defined(CONFIG_ARCH_OMAP2PLUS) \
|
2014-04-23 12:20:43 +00:00
|
|
|
|| defined(CONFIG_EXYNOS4) || defined(CONFIG_EXYNOS5) \
|
2018-08-27 10:27:11 +00:00
|
|
|
|| defined(CONFIG_EXYNOS4210) || defined(CONFIG_ARCH_K3)
|
2012-08-14 15:50:58 +00:00
|
|
|
/* Platform-specific defines */
|
|
|
|
|
#include <asm/arch/spl.h>
|
|
|
|
|
|
2014-04-23 12:20:43 +00: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 10:12:31 +00:00
|
|
|
BOOT_DEVICE_USB,
|
2014-04-23 12:20:43 +00:00
|
|
|
BOOT_DEVICE_SATA,
|
|
|
|
|
BOOT_DEVICE_I2C,
|
2015-02-07 17:47:29 +00:00
|
|
|
BOOT_DEVICE_BOARD,
|
2016-08-30 13:38:57 +00:00
|
|
|
BOOT_DEVICE_DFU,
|
2017-05-28 19:55:11 +00:00
|
|
|
BOOT_DEVICE_XIP,
|
2017-06-22 21:38:36 +00: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 20:59:19 +00:00
|
|
|
BOOT_DEVICE_SMH,
|
2014-04-23 12:20:43 +00:00
|
|
|
BOOT_DEVICE_NONE
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-08-22 22:31:05 +00:00
|
|
|
/* Linker symbols. */
|
2013-03-14 06:54:53 +00:00
|
|
|
extern char __bss_start[], __bss_end[];
|
2012-08-22 22:31:05 +00:00
|
|
|
|
2015-03-03 15:02:58 +00:00
|
|
|
#ifndef CONFIG_DM
|
2012-08-22 22:31:05 +00:00
|
|
|
extern gd_t gdata;
|
2015-03-03 15:02:58 +00:00
|
|
|
#endif
|
2012-08-22 22:31:05 +00:00
|
|
|
|
2012-08-14 15:50:58 +00:00
|
|
|
#endif
|
