summaryrefslogtreecommitdiff
path: root/common/spl
AgeCommit message (Collapse)Author
2024-10-25Merge tag 'u-boot-imx-master-20241025a' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-imx CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22989 - Remove unneeded USB board code and fix reset on mx6ul_14x14_evk. - Update fastboot buffer size/address for verdin-imx8m{m|p}. - Fix imxrt1050-evk boot and convert it to standard boot. - Fix imx8qxp-mek and imx8qm-mek boot. - Add support for the i.MX93 9X9 QSB board. - Make livetree API to work on i.MX. - Set sane default value for i.MX8M SPL_LOAD_FIT_ADDRESS. - Deduplicate DH i.MX8MP/i.MX6 DHSOM defconfigs. - Select default TEXT_BASE for i.MX6/i.MX7. - Several updates for DH i.MX8MP DRC02.
2024-10-25ARM: imx: soc: Move default TEXT_BASE for i.MX7Marek Vasut
Move i.MX7 TEXT_BASE/SPL_TEXT_BASE to Kconfig and common/spl/Kconfig which is the best practice. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2024-10-25ARM: imx: soc: Select default TEXT_BASE for i.MX6Marek Vasut
Select default U-Boot and SPL text base for the i.MX6 SoC. The U-Boot and SPL text base is picked as the one used by various i.MX6 boards. Update all the boards. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2024-10-25common: Tidy up how malloc() is initedSimon Glass
The call to malloc() is a bit strange. The naming of the arguments suggests that an address is passed, but in fact it is a pointer, at least in the board_init_r() function and SPL equivalent. Update it to work as described. Add a function comment as well. Note that this does adjustment does not extend into the malloc() implementation itself, apart from changing mem_malloc_init(), since there are lots of casts and pointers and integers are used interchangeably. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Tom Rini <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-10-16net: introduce alternative implementation as net/lwip/Jerome Forissier
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net/lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP because of dependencies on net_loop(), tftp_timeout_ms, tftp_timeout_count_max and other NET things. Let's add a dependency on !NET_LWIP for now. SANDBOX can select NET_LWIP but doing so will currently disable the eth dm tests as well as the wget tests which have strong dependencies on the NET code. Other adjustments to Kconfig files are made to fix "unmet direct dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when the default networking stack is set to NET_LWIP ("default NET_LWIP" instead of "default NET" in Kconfig). The networking stack is now a choice between NO_NET, NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be 'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly. Signed-off-by: Jerome Forissier <[email protected]> Acked-by: Ilias Apalodimas <[email protected]>
2024-10-11Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"Tom Rini
Simon Glass <[email protected]> says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.
2024-10-11spl: Rename SPL_TPL_NAME and SPL_TPL_PROMPTSimon Glass
Rename these to use the word PHASE instead. Signed-off-by: Simon Glass <[email protected]>
2024-10-11global: Rename SPL_TPL_ to PHASE_Simon Glass
Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass <[email protected]>
2024-10-11global: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILDSimon Glass
Complete this rename for all directories outside arch/ board/ drivers/ and include/ Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename spl_phase_prefix() and spl_phase_name()Simon Glass
Use simpler names for these functions. Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename spl_next_phase() and spl_prev_phase()Simon Glass
Rename this to use the xpl prefix. Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename spl_phase() to xpl_phase()Simon Glass
Rename this function to indicate that it refers to any xPL phase. Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename spl_phase to xpl_phase_tSimon Glass
This name fits better with the new naming scheme, so update it. Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename u_boot_first_phase to xpl_is_first_phase()Simon Glass
This is a better name for this function, so update it. Tidy up the function comment to mention VPL. Signed-off-by: Simon Glass <[email protected]>
2024-10-07Merge branch 'next'Tom Rini
2024-10-03Merge patch series "vbe: Series part D"Tom Rini
Simon Glass <[email protected]> says: This includes various patches towards implementing the VBE abrec bootmeth in U-Boot.
2024-10-03mmc: Add more debugging for SPLSimon Glass
When MMC booting fails it is sometimes hard to figure out what went wrong as there is no error code. It isn't even clear which MMC device was chosen, since SPL can have its own numbering. Add some debugging to help with this. Signed-off-by: Simon Glass <[email protected]>
2024-10-03Merge patch series "arm: Initial support for Analog Devices SC5xx boards"Tom Rini
Oliver Gaskell <[email protected]> says: ADSP-SC5xx is a series of ARM-based DSPs. This comprises the armv7 based SC57x, SC58x and SC594 series, and the armv8 based SC598. This patch series includes configurations, init code, and minimal DTs to enable Analog Devices' evaluation boards for these SoCs to boot through SPL and into U-Boot Proper, as well as devicetree schemas for the added DTs. This patch series depends on ("arm: Add Analog Devices SC5xx Machine Type") (https://lists.denx.de/pipermail/u-boot/2024-April/552043.html)
2024-10-03arm: SC573-EZKIT initial supportOliver Gaskell
Adds support for Analog Devices' SC573-EZKIT board. Includes: - SoC specific configs in mach-sc5xx/Kconfig - Memory Map for SPL - Necessary board-specific init functions - Board-specific Kconfig and environment in board/adi/ - Memory configuration Co-developed-by: Greg Malysa <[email protected]> Signed-off-by: Greg Malysa <[email protected]> Co-developed-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Oliver Gaskell <[email protected]>
2024-10-03arm: SC584-EZKIT initial supportOliver Gaskell
Adds support for Analog Devices' SC584-EZKIT board. Includes: - SoC specific configs in mach-sc5xx/Kconfig - Memory Map for SPL - SPL config options in common/spl/Kconfig - Necessary board-specific init functions - Board-specific Kconfig and environment in board/adi/ - Memory configuration Co-developed-by: Greg Malysa <[email protected]> Signed-off-by: Greg Malysa <[email protected]> Co-developed-by: Trevor Woerner <[email protected]> Signed-off-by: Trevor Woerner <[email protected]> Co-developed-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Oliver Gaskell <[email protected]>
2024-10-03arm: SC594-SOM-EZLITE initial supportOliver Gaskell
Adds support for Analog Devices' SC594-SOM-EZLITE board. Includes: - Board specific configs in mach-sc5xx/Kconfig - Board-specific Kconfig and environment in board/adi/ Signed-off-by: Oliver Gaskell <[email protected]>
2024-10-03arm: SC594-SOM-EZKIT initial supportOliver Gaskell
Adds support for Analog Devices' SC594-SOM-EZKIT board. Includes: - SoC specific configs in mach-sc5xx/Kconfig - Memory Map for SPL - SPL config options in common/spl/Kconfig - Necessary board-specific init functions - Board-specific Kconfig and environment in board/adi/ - Memory configuration Co-developed-by: Greg Malysa <[email protected]> Signed-off-by: Greg Malysa <[email protected]> Co-developed-by: Trevor Woerner <[email protected]> Signed-off-by: Trevor Woerner <[email protected]> Co-developed-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Nathan Barrett-Morrison <[email protected]> Co-developed-by: Ian Roberts <[email protected]> Signed-off-by: Ian Roberts <[email protected]> Signed-off-by: Oliver Gaskell <[email protected]>
2024-10-03arm: SC598-SOM-EZKIT initial supportOliver Gaskell
Adds support for Analog Devices' SC598-SOM-EZKIT board. Includes: - CONFIG options common to all SC5xx SoCs - SoC specific configs in mach-sc5xx/Kconfig - SPL config options in common/spl/Kconfig - Memory Map for SPL - Necessary board-specific init functions - Board-specific Kconfig and environment in board/adi/ - Memory configuration Co-developed-by: Greg Malysa <[email protected]> Signed-off-by: Greg Malysa <[email protected]> Co-developed-by: Nathan Barrett-Morrison <[email protected]> Signed-off-by: Nathan Barrett-Morrison <[email protected]> Co-developed-by: Trevor Woerner <[email protected]> Signed-off-by: Trevor Woerner <[email protected]> Signed-off-by: Oliver Gaskell <[email protected]>
2024-10-03Update the ARM trusted firmware git URLPeter Robinson
The primary upstream URL for tf-a has moved, in some cases things like tags are not always pushed to the old URL so update the URLs to the primary upstream project URL. Signed-off-by: Peter Robinson <[email protected]>
2024-09-24spl: ram: hide SPL_RAM_SUPPORTJerome Forissier
Make SPL_RAM_SUPPORT a hidden Kconfig symbol, automatically selected by SPL_RAM_DEVICE or SPL_DFU. Avoids the situation where SPL_RAM_SUPPORT may be enabled without the other two being enabled, which results in the following build warning: common/spl/spl_ram.c:19:14: warning: ‘spl_ram_load_read’ defined but not used [-Wunused-function] 19 | static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector, | ^~~~~~~~~~~~~~~~~ Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Tom Rini <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]>
2024-09-05Merge patch series "provide names for emmc hardware partitions"Tom Rini
Tim Harvey <[email protected]> says: Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC specification described as: Boot Area Partition 1 Boot Area Partition 2 RPMB Partition General Purpose Partition 1 General Purpose Partition 2 General Purpose Partition 3 General Purpose Partition 4 User Data Area These are referenced by fields in the PARTITION_CONFIG register (Extended CSD Register 179) which is defined as: bit 7: reserved bit 6: BOOT_ACK 0x0: No boot acknowledge sent (default 0x1: Boot acknowledge sent during boot operation Bit bit 5:3: BOOT_PARTITION_ENABLE 0x0: Device not boot enabled (default) 0x1: Boot Area partition 1 enabled for boot 0x2: Boot Area partition 2 enabled for boot 0x3-0x6: Reserved 0x7: User area enabled for boot bit 2:0 PARTITION_ACCESS 0x0: No access to boot partition (default) 0x1: Boot Area partition 1 0x2: Boot Area partition 2 0x3: Replay Protected Memory Block (RPMB) 0x4: Access to General Purpose partition 1 0x5: Access to General Purpose partition 2 0x6: Access to General Purpose partition 3 0x7: Access to General Purpose partition 4 Note that setting PARTITION_ACCESS to 0x0 results in selecting the User Data Area partition. You can see above that the two fields BOOT_PARTITION_ENABLE and PARTITION_ACCESS do not use the same enumerated values. U-Boot uses a set of macros to access fields of the PARTITION_CONFIG register: EXT_CSD_BOOT_ACK_ENABLE (1 << 6) EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3) EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0) EXT_CSD_PARTITION_ACCESS_DISABLE (0 << 0) EXT_CSD_BOOT_ACK(x) (x << 6) EXT_CSD_BOOT_PART_NUM(x) (x << 3) EXT_CSD_PARTITION_ACCESS(x) (x << 0) EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1) EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7) EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7) There are various places in U-Boot where the BOOT_PARTITION_ENABLE field is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a hardware partition consistent with the definition of the PARTITION_ACCESS field used by the various mmc_switch incarnations. To add some sanity to the distinction between BOOT_PARTITION_ENABLE (used to specify the active device on power-cycle) and PARTITION_ACCESS (used to switch between hardware partitions) create two enumerated types and use them wherever struct mmc * part_config is used or the above macros are used. Additionally provide arrays of the field names and allow those to be used in the 'mmc partconf' command and in board support files. The first patch adds enumerated types and makes use of them which represents no compiled code change. The 2nd patch adds the array of names and uses them in the 'mmc partconf' command. The 3rd patch uses the array of hardware partition names in a board support file to show what emmc hardware partition U-Boot is being loaded from.
2024-09-05mmc: use an enumerated type to represent PARTITION_CONFIG fieldsTim Harvey
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC specification described as: Boot Area Partition 1 Boot Area Partition 2 RPMB Partition General Purpose Partition 1 General Purpose Partition 2 General Purpose Partition 3 General Purpose Partition 4 User Data Area These are referenced by fields in the PARTITION_CONFIG register (Extended CSD Register 179) which is defined as: bit 7: reserved bit 6: BOOT_ACK 0x0: No boot acknowledge sent (default 0x1: Boot acknowledge sent during boot operation Bit bit 5:3: BOOT_PARTITION_ENABLE 0x0: Device not boot enabled (default) 0x1: Boot Area partition 1 enabled for boot 0x2: Boot Area partition 2 enabled for boot 0x3-0x6: Reserved 0x7: User area enabled for boot bit 2:0 PARTITION_ACCESS 0x0: No access to boot partition (default) 0x1: Boot Area partition 1 0x2: Boot Area partition 2 0x3: Replay Protected Memory Block (RPMB) 0x4: Access to General Purpose partition 1 0x5: Access to General Purpose partition 2 0x6: Access to General Purpose partition 3 0x7: Access to General Purpose partition 4 Note that setting PARTITION_ACCESS to 0x0 results in selecting the User Data Area partition. You can see above that the two fields BOOT_PARTITION_ENABLE and PARTITION_ACCESS do not use the same enumerated values. U-Boot uses a set of macros to access fields of the PARTITION_CONFIG register: There are various places in U-Boot where the BOOT_PARTITION_ENABLE field is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a hardware partition consistent with the definition of the PARTITION_ACCESS field which is also the value used to specify the hardware partition of the various mmc_switch incarnations. To add some sanity to the distinction between BOOT_PARTITION_ENABLE (used to specify the active device on power-cycle) and PARTITION_ACCESS (used to switch between hardware partitions) create two enumerated types and use them wherever struct mmc * part_config is used or the above macros are used. This represents no code changes. Signed-off-by: Tim Harvey <[email protected]>
2024-09-03Merge patch series "Make LMB memory map global and persistent"Tom Rini
Sughosh Ganu <[email protected]> says: This is a follow-up from an earlier RFC series [1] for making the LMB and EFI memory allocations work together. This is a non-rfc version with only the LMB part of the patches, for making the LMB memory map global and persistent. This is part one of a set of patches which aim to have the LMB and EFI memory allocations work together. This requires making the LMB memory map global and persistent, instead of having local, caller specific maps. This is being done keeping in mind the usage of LMB memory by platforms where the same memory region can be used to load multiple different images. What is not allowed is to overwrite memory that has been allocated by the other module, currently the EFI memory module. This is being achieved by introducing a new flag, LMB_NOOVERWRITE, which represents memory which cannot be re-requested once allocated. The data structures (alloced lists) required for maintaining the LMB map are initialised during board init. The LMB module is enabled by default for the main U-Boot image, while it needs to be enabled for SPL. This version also uses a stack implementation, as suggested by Simon Glass to temporarily store the lmb structure instance which is used during normal operation when running lmb tests. This does away with the need to run the lmb tests separately. The tests have been tweaked where needed because of these changes. The second part of the patches, to be sent subsequently, would work on having the EFI allocations work with the LMB API's. [1] - https://lore.kernel.org/u-boot/[email protected]/T/#t Notes: 1) These patches are on next, as the alist patches have been applied to that branch. 2) I have tested the boot on the ST DK2 board, but it would be good to get a T-b/R-b from the ST maintainers. 3) It will be good to test these changes on a PowerPC platform (ideally an 85xx, as I do not have one).
2024-09-03spl: call spl_board_init() at the end of the spl init sequenceSughosh Ganu
The spl_board_init() function on sandbox invokes the unit tests. Invoking the tests should be done once the rest of the system has been initialised. Call the spl_board_init() function at the very end, once the rest of the initilisation functions have been called, including the setting up of the LMB memory map. Signed-off-by: Sughosh Ganu <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-09-03lmb: init: initialise the lmb data structures during board initSughosh Ganu
The memory map maintained by the LMB module is now persistent and global. This memory map is being maintained through the alloced list structure which can be extended at runtime -- there is one list for the available memory, and one for the used memory. Allocate and initialise these lists during the board init. Signed-off-by: Sughosh Ganu <[email protected]> Reviewed-by: Simon Glass <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-08-30Merge patch series "Add support for Ethernet Boot on SK-AM62"Tom Rini
Chintan Vankar <[email protected]> says: This series enables Ethernet Boot on SK-AM62 device. This series is based on commit 'f4f845b85926' of origin/next branch of U-Boot. Logs for Ethernet Boot for AM625-SK: https://gist.github.com/chintanv133/464782796a9a60b9f5a49e674c5fc31a
2024-08-30common: spl: spl: Init DRAM size in R5/A53 SPLChintan Vankar
Initialize DRAM size in SPL stage since networking requires DDR to be initialized. Reviewed-by: Dhruva Gole <[email protected]> Reviewed-by: Tom Rini <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Chintan Vankar <[email protected]>
2024-08-26global_data: Reduce size of early-malloc varsSimon Glass
The early malloc region is normally quite small and is certainly less than 4GB, so use a 32-bit value for the limit and pointer. Update the comments for clarity while we are here. Signed-off-by: Simon Glass <[email protected]>
2024-08-26global_data: Convert have_console into a flagSimon Glass
We don't need a full word for this boolean value. Convert it into a flag to save space in global_data. Reviewed-by: Alexander Sverdlin <[email protected]> Signed-off-by: Simon Glass <[email protected]>
2024-08-23spl: Create a function to init spl_load_infoSimon Glass
Rather than having every caller set this up individually, create a common init function. This allows new fields to be added without the risk of them being left uninited. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Michael Trimarchi <[email protected]>
2024-08-23spl: Remove remaining #ifdef in spl_parse_image_header()Simon Glass
Define spl_set_header_raw_uboot() always so we can drop the last #ifdef in this function. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-08-23spl: Remove some #ifdefs in spl_parse_image_header()Simon Glass
This function has a number of unnecessary #ifdefs so remove them. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-08-23spl: mmc: Try to clean up raw-mode optionsSimon Glass
Make the raw-mode options depend on SPL_SYS_MMCSD_RAW_MODE in a more direct way. This makes it easier to understand the options with 'make menuconfig'. There are three different ways of specifying the offset: - sector offset - partition number - partition type So make these a choice, so it is more obvious what is going on. Update existing boards to enable SPL_SYS_MMCSD_RAW_MODE where needed. Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Signed-off-by: Simon Glass <[email protected]>
2024-08-23spl: Correct use of CMD_BOOTI and CMD_BOOTZSimon Glass
These should have a CONFIG_ prefix. Add it. Signed-off-by: Simon Glass <[email protected]> Fixes: 7a0d88076b9 ("Add in the ability to load and boot an uncompr...") Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-08-23spl: mmc: Adjust args of spl_mmc_find_device()Simon Glass
At present spl_mmc_load() is the only caller of this function, passing it a boot_device, an index into the available MMC devices. Pass the device number instead, since it is known by the caller and simplifies the code. Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-08-23spl: mmc: Handle error codes consistentlySimon Glass
Use 'ret' as the return code, since it may not be an error and this is the common name in U-Boot. Make sure to return the error code when given, rather than transforming it into -1 (-EPERM). Signed-off-by: Simon Glass <[email protected]>
2024-08-23spl: mmc: Drop checks for CONFIG_SPL_LIBCOMMON_SUPPORTSimon Glass
This check is not needed now, since printf() resolved to nothing if not available. Drop the #ifdefs Signed-off-by: Simon Glass <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Quentin Schulz <[email protected]>
2024-08-19Merge tag 'v2024.10-rc3' into nextTom Rini
Prepare v2024.10-rc3
2024-08-13spl: binman: Disable u_boot_any symbols for i.MX 8ULP boardsGary Bisson
This is extending commit da96f93cda9 ("spl: binman: Disable u_boot_any symbols for i.MX93 boards") to i.MX 8ULP boards. Signed-off-by: Gary Bisson <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2024-08-09Merge patch series "Universal Payload initial series"Tom Rini
Simon Glass <[email protected]> says: Universal Payload (UPL) is an Industry Standard for firmware components[1]. UPL is designed to improve interoperability within the firmware industry, allowing mixing and matching of projects with less friction and fewer project-specific implementations. UPL is cross-platform, supporting ARM, x86 and RISC-V initially. This series provides some initial support for this, targeting 0.9.1 and sandbox only. Features still to come include: - Support for architectures - FIT validation - Handoff validation - Interoperability tests
2024-08-09spl: Plumb in the Universal Payload handoffSimon Glass
Specify the FIT and include information about each loaded image, as required by the UPL handoff. Write the UPL handoff into the bloblist before jumping to the next phase. Control this using a runtime flag to avoid conflicting with other handoff mechanisms. Signed-off-by: Simon Glass <[email protected]>
2024-08-09spl: Set SPL_FIT_FOUND for full FIT alsoSimon Glass
This flag is set for simple FIT, so set it for full FIT too. Signed-off-by: Simon Glass <[email protected]>
2024-08-09upl: Add support for Universal Payload in SPLSimon Glass
Add the basic code to create a handoff structure in SPL, so it can be passed to the next phase. For now this is not plumbed in. Signed-off-by: Simon Glass <[email protected]>
2024-08-06omap3: Define maximum SPL size in Kconfig instead of defconfigsPaul Kocialkowski
The maximum SPL size was defined to the same value in each OMAP3 board defconfig. Move the common definition to the Kconfig option declaration instead. Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Tom Rini <[email protected]> Tested-by: Derald D. Woods <[email protected]>
2024-08-06omap3: Define common SPL text base in Kconfig instead of defconfigsPaul Kocialkowski
The SPL text base was defined to the same value in each OMAP3 board defconfig. Move the common definition to the Kconfig option declaration instead. Signed-off-by: Paul Kocialkowski <[email protected]> Tested-by: Adam Ford <[email protected]> #am3517-evm Reviewed-by: Tom Rini <[email protected]> Tested-by: Derald D. Woods <[email protected]>