u-boot/common/spl/Makefile

39 lines
1.5 KiB
Makefile
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0+
#
# (C) Copyright 2012
# Texas Instruments Incorporated - http://www.ti.com/
# Aneesh V <aneesh@ti.com>
# Based on common/Makefile.
#
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
obj-$(CONFIG_$(SPL_TPL_)BOOTROM_SUPPORT) += spl_bootrom.o
obj-$(CONFIG_$(SPL_TPL_)LOAD_FIT) += spl_fit.o
obj-$(CONFIG_$(SPL_TPL_)BLK_FS) += spl_blk_fs.o
obj-$(CONFIG_$(SPL_TPL_)LEGACY_IMAGE_FORMAT) += spl_legacy.o
obj-$(CONFIG_$(SPL_TPL_)NOR_SUPPORT) += spl_nor.o
obj-$(CONFIG_$(SPL_TPL_)XIP_SUPPORT) += spl_xip.o
obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += spl_ymodem.o
ifndef CONFIG_SPL_UBI
obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += spl_nand.o
obj-$(CONFIG_$(SPL_TPL_)ONENAND_SUPPORT) += spl_onenand.o
endif
obj-$(CONFIG_$(SPL_TPL_)UBI) += spl_ubi.o
obj-$(CONFIG_$(SPL_TPL_)NET) += spl_net.o
obj-$(CONFIG_$(SPL_TPL_)MMC) += spl_mmc.o
obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o
obj-$(CONFIG_$(SPL_TPL_)OPTEE_IMAGE) += spl_optee.o
obj-$(CONFIG_$(SPL_TPL_)OPENSBI) += spl_opensbi.o
obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
obj-$(CONFIG_$(SPL_TPL_)FS_FAT) += spl_fat.o
obj-$(CONFIG_$(SPL_TPL_)FS_EXT4) += spl_ext.o
obj-$(CONFIG_$(SPL_TPL_)SATA) += spl_sata.o
obj-$(CONFIG_$(SPL_TPL_)NVME) += spl_nvme.o
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
obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += spl_semihosting.o
obj-$(CONFIG_$(SPL_TPL_)DFU) += spl_dfu.o
obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
obj-$(CONFIG_$(SPL_TPL_)RAM_SUPPORT) += spl_ram.o
obj-$(CONFIG_$(SPL_TPL_)USB_SDP_SUPPORT) += spl_sdp.o
endif