summaryrefslogtreecommitdiff
path: root/arch/arm/mach-stm32mp
AgeCommit message (Collapse)Author
7 daysARM: stm32: fix PRE_CON_BUF_ADDR on STM32MP13Patrick Delaunay
Since SYS_MALLOC_F_LEN increasing to 0x2100000 on STM32MP13, the pre-console buffer is overlapped by stack (0xC0400000 + 0x2100000), so the this buffer must be moved just before the bootstage to avoid issue. After this patch the pre-relocation memory mapping for STM32MP13x is: C3000000 = Bootstage CONFIG_BOOTSTAGE_STASH_ADDR C2FFF000 = PreConsole CONFIG_PRE_CON_BUF_ADDR with size CONFIG_PRE_CON_BUF_SZ = 4096 C0400000 = start for stack with CONFIG_CUSTOM_SYS_INIT_SP_ADDR including CONFIG_SYS_MALLOC_F_LEN C0000000 = Load Address of U-Boot with CONFIG_TEXT_BASE Fixes: 93c962c7af7e ("configs: stm32mp13: increase SYS_MALLOC_F_LEN to 0x210000") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
7 daysarm: stm32mp: replace space by tab in sys_proto.hPatrice Chotard
Cosmetic update to replace space by tab in sys_proto.h Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
7 daysARM: stm32mp: Add STM32MP23 supportPatrice Chotard
Add STM32MP23 support which is a cost optimized of STM32MP25. More details available at: https://www.st.com/en/microcontrollers-microprocessors/stm32mp2-series.html Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
7 daysARM: stm32: Limit early cache enablement in SPL to STM32MP15xxMarek Vasut
The STM32MP13xx SRAM size is half that the SRAM size on STM32MP15xx, disable early dcache start on STM32MP13xx as the TLB itself takes about a quarter of the SPL size. The dcache will be enabled later, once DRAM is available and TLB can be placed in DRAM. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
7 daysARM: stm32: Add STM32MP13xx SPL hardware initializationMarek Vasut
Add hardware initialization for the STM32MP13xx in SPL. This is similar to STM32MP15xx except the code has to enable MCE to bring DRAM controller up later. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
7 daysARM: stm32: Add STM32MP13xx SPL Kconfig optionsMarek Vasut
Introduce Kconfig options used by SPL on STM32MP13xx and isolate the Kconfig options only used in case TFA BL2 is used as a SPL behind CONFIG_TFABOOT dependency. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
7 daysarm: stm32mp2: add multifunction timer support for stm32mp25Cheick Traore
Add support for STM32MP25 SoC. Identification and hardware configuration registers allow to read the timer version and capabilities (counter width, ...). So, rework the probe to avoid touching ARR register by simply read the counter width when available. This may avoid messing with a possibly running timer. Also add useful bit fields to stm32-timers header file. Signed-off-by: Cheick Traore <cheick.traore@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-06-13spl: Rename jump_to_image_no_args()Simon Glass
This function is currently a misnomer at times as we have cases where it passes arguments to the image. In preparation for making that be a more common case rename this function to jump_to_image(...). In order to do this, rename jump_to_image in board_init_r(...) to jumper so that we do not have a conflict. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Reword the commit message, adding missing cases of jump_to_image_no_args()] Signed-off-by: Tom Rini <trini@konsulko.com>
2025-06-11stm32mp: Add tamp_nvram driverSimeon Marijon
TAMP backup registers will be exposed as nvmem cells. Each registers ([0..127] for STM32MP2, [0..31] for STM32MP1) could be exposed as nvmem cells under the nvram node in device tree Signed-off-by: Simeon Marijon <simeon.marijon@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-06-11ARM: stm32: Auto-detect ROM API table on STM32MP15xxMarek Vasut
The ROM API table location is passed to the SPL by BootROM in register r0, make use of this, store the content of r0 and later use it to access the ROM API table to determine current boot device. Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-06-11ARM: stm32: Fix DBGMCU macro on STM32MP13xxMarek Vasut
The DBGMCU block is available at address 0x50081000 both on STM32MP13xx and on STM32MP15xx . There is no reason to limit the DBGMCU macro being set only on STM32MP15xx , remove the ifdeffery. Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-06-11ARM: stm32: Fix SYSRAM size on STM32MP13xxMarek Vasut
The STM32MP13xx has only 128 kiB of SYSRAM starting at address 0x2ffe0000 . The STM32MP15xx has 256 kiB of SYSRAM starting at address 0x2ffc0000 . Make sure both SoCs configure ARMV7_SECURE_BASE correctly . Define the SYSRAM base in stm32.h to be consistent with the STM32MP15xx macro. Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-06-11ARM: stm32: Drop unnecessary spaceMarek Vasut
Drop a space after tab, no functional change. Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-06-02Merge patch series "Audit include list for include/[a-m]*.h"Tom Rini
Tom Rini <trini@konsulko.com> says: Hey all, Related to my other series I've posted recently on cleaning up some headers, this series here is the result of at least lightly auditing the #includes used in include/[a-m]*.h. This ignores subdirectories, as at least in part I think the top-level includes we've constructed are the most likely places to have some extra transitive include paths. I'm sure there's exceptions and I'll likely audit deeper once this first pass is done. This only gets as far as "include/m*.h" because I didn't want this to get too big. This also sets aside <miiphy.h> and <phy.h>. While miiphy.h does not directly need <phy.h> there are *so* many users and I think I had half of the tree just about not building when I first tried. It might be worth further investigation, but it might just be OK as-is. Link: https://lore.kernel.org/r/20250521230119.2084088-1-trini@konsulko.com
2025-06-02include/mtd.h: Cleanup usageTom Rini
There are only a few things found in <mtd.h> today. Go through and audit the C files which include <mtd.h> and remove it when not required. Then, add it to the files which had either missed it or had an indirect inclusion of it. Signed-off-by: Tom Rini <trini@konsulko.com>
2025-05-29global: Avoid indirect inclusion of <env.h> from <command.h>Tom Rini
The include file <command.h> does not need anything from <env.h>. Furthermore, include/env.h itself includes other headers which can lead to longer indirect inclusion paths. To prepare to remove <env.h> from <command.h> fix all of the places which had relied on this indirect inclusion to instead include <env.h> directly. Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn Signed-off-by: Tom Rini <trini@konsulko.com>
2025-04-25arm: stm32mp: stm32prog: add support rootfs-a for OTAPatrick Delaunay
Add support of "rootfs-a" name to allow support of A/B mechanism for OTA on rootfs. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: stm32prog: PTA BSEC is not supported on closed devicePatrick Delaunay
On closed device the PTA BSEC is never supported and the current check if PTA BSEC is supported cause a OP-TEE error: E/TC tee_ta_open_session This patch removed this warning on closed device, because the check is skipped. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: add helper function stm32mp_is_closed()Patrick Delaunay
Add the helper function stm32mp_is_closed() to check the "closed" state in product life cycle, when product secrets have been provisioned into the device, by "secure secret provisioning" tools (SSP) for example. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: cmd_stm32key: update command for stm32mp25xPatrice Chotard
Update key table for stm32mp25 platform. Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com> Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: fix package IDs for stm32mp25Patrice Chotard
Fix package IDs for stm32mp25. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: implement new STM32MP25 revision ID systemPatrick Delaunay
The STM32MP25 revision ID are now defined with the OTP102, this patch implements this new system. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: disable console for UART serial bootPatrice Chotard
For UART serial boot, the console need to be deactivated to avoid issue with tools STM32CubeProgrammer. This patch adds also the missing dependency for CMD_STM32PROG_SERIAL, to allow the silent and disable console. This avoid to add is on board level for STM32MP15 (with TARGET_ST_STM32MP15X or TARGET_ST_STM32MP13X) Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: increase EARLY_TLB_SIZE to 0x10000Patrice Chotard
Depending on Soc (STM32MP25 vs STM32MP21), the memory map can be different and it generates a different TLB page table configuration/size. Increase EARLY_TLB_SIZE to 0x10000 to fix following error message and panic: "Insufficient RAM for page table: 0xb000 > 0xa000. Please increase the size in get_page_table_size()" Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25arm: stm32mp: add boot_mode support for STM32MP25Patrick Delaunay
Add support of all the boot mode supported by STM32MP25x family with information provided by TF-A in backup register Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-04-25ARM: stm32mp: add RIFSC system bus driver for STM32MP25Patrick Delaunay
This driver is checking the access rights of the different peripherals connected to the RIFSC bus. If access is denied, the associated device is not binded. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Cover-letter: Enable OF_UPSTREAM for STM32 and STi platforms This series is enabling OF_UPSTREAM flag for STM32 MCU's, MPU's and STi platforms. For some boards, some defconfig and DT update are needed to keep the same functional level. The major impact concerns MPU's platform with introduction of STM32 System Bus. END Series-version: 2 Series-changes: 2 - Replace LOG_CATEGORY UCLASS_SIMPLE_BUS by UCLASS_NOP in both /arch/arm/mach-stm32mp/stm32mp2/rifsc.c and /arch/arm/mach-stm32mp/stm32mp1/etzpc.c. - Update board/st/stm32mp1/MAINTAINERS. - Fix DSI clock ssetting.
2025-04-25ARM: dts: stm32: convert stm32mp2 board to OF_UPSTREAMPatrice Chotard
Enable OF_UPSTREAM flag for STM32MP2 platforms. Add fixed-clock ck_flexgen_08 and ck_icn_ls_mcu until STM32MP25 clock driver will be available. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-04-25stm32mp: fdt: remove ETZPC peripheral cleanupLionel Debieve
Due to feature domains management, there is no more need to maintain the fdt cleanup. Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-04-25ARM: stm32mp: add ETZPC system bus driver for STM32MP1Lionel Debieve
This driver is checking the access rights of the different peripherals connected to the ETZPC bus. If access is denied, the associated device is not bound. Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-04-25ARM: dts: stm32: convert stm32mp15 board to OF_UPSTREAMPatrice Chotard
Enable OF_UPSTREAM flag for STM32MP15 platforms, except for stm32mp15-odyssey,see following patch : "configs: stm32: introduce stm32mp15-odyssey_defconfig" Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-04-25ARM: dts: stm32: convert stm32mp13 board to OF_UPSTREAMPatrice Chotard
Enable OF_UPSTREAM flag for STM32MP13 platforms. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-04-11Kbuild: Always use $(PHASE_)Tom Rini
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <trini@konsulko.com>
2025-03-12Merge tag 'u-boot-stm32-20250312' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-stm into next CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25112 - Add drivers for MFD STM32 TIMERS and STM32 PWM and enable them on stm32mp135f-dk - Restrict _debug_uart_init() usage in STM32 serial driver - Add support for environment in eMMC on STM32MP13xx DHCOR SoM - Introduce DH STM32MP15xx DHSOM board specific defconfigs - Fix CONFIG_BOOTCOUNT_ALTBOOTCMD update on DH STM32MP1 DHSOM - Update maintainer for board stm32f746-disco - Fix Linux cmdline for stm32f769-disco - Cleanup in stm32f***-u-boot.dtsi and in board_late_init() by removing legacy led and button management.
2025-03-12serial: stm32: restrict _debug_uart_init() usagePatrice Chotard
Since commit 948da7773e34 ("arm: Add new config option ARCH_VERY_EARLY_INIT") debug_uart_init() is called respectively in crt0.S and crt0_64.S. That means that _debug_uart_init() is called for all STM32MP platforms even for those which doesn't support SPL_BUILD. So restrict _debug_uart_init() execution for platforms which can have SPL_BUILD enabled (STM32MP1 platform only). It's more needed to call debug_uart_init() in stm32mp1/cpu.c. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-03-12mach-stm32: add multifunction timer driver supportCheick Traore
Add support for STM32MP timer multi-function driver. These timers can be use as counter, trigger or pwm generator. This driver will be used to manage the main resources of the timer to provide them to the functionnalities which need these ones. Signed-off-by: Cheick Traore <cheick.traore@foss.st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-03-10ARM: stm32mp: Fix dram_bank_mmu_setup() for ram_top=0Marek Vasut
On STM32MP15xx with 1 GiB of DRAM, the gd->ram_top becomes 0, because DRAM base 0xc0000000 + DRAM size 0x40000000 leads to gd->ram_top overflow which resets it to 0. Handle this special case simply by checking for gd->ram_top being zero, and if it is, assume there is no addr >= gd->ram_top . This fixes boot hang on STM32MP15xx with 1 GiB of DRAM. Fixes: 25fb58e88aba ("ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_top") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2025-01-31stm32mp: Fix board_get_usable_ram_top()Patrice Chotard
mmu_set_region_dcache_behaviour() parameters must be aligned which is not always the case. For example for STM32MP2, we stayed stuck inside mmu_set_region_dcache_behaviour() in an infinite loop because set_one_region() always return 0 due to start parameter which is not aligned. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-01-31arm: stm32mp: stm32prog: update multiplier is part-size is above SZ_1GPatrice Chotard
Set multiplier to 'G' if part->size if above SZ_1G. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2025-01-31arm: stm32mp: stm32prog: fix warning when CONFIG_SYS_64BIT_LBA is enablePatrice Chotard
If CONFIG_SYS_64BIT_LBA flag is enable, following warning is triggered: ../arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c: In function 'init_device': ../arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:793:27: warning: format '%ld' expects argument of type 'long int', but argument 8 has type 'lbaint_t' {aka 'long long unsigned int'} [-Wformat=] 793 | log_debug("MMC %d: lba=%ld blksz=%ld\n", dev->dev_id, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/log.h:157:21: note: in definition of macro 'pr_fmt' 157 | #define pr_fmt(fmt) fmt | ^~~ ../include/log.h:182:33: note: in expansion of macro 'log' 182 | #define log_debug(_fmt...) log(LOG_CATEGORY, LOGL_DEBUG, ##_fmt) | ^~~ ../arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:793:17: note: in expansion of macro 'log_debug' 793 | log_debug("MMC %d: lba=%ld blksz=%ld\n", dev->dev_id, | ^~~~~~~~~ ../arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:793:42: note: format string is defined here 793 | log_debug("MMC %d: lba=%ld blksz=%ld\n", dev->dev_id, | ~~^ | | | long int | %lld Cast block_dev->lba to u64 and set the length specifier to %lld which is ok with or without CONFIG_SYS_64BIT_LBA flag. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-12-25Merge tag 'v2025.01-rc5' into nextTom Rini
Prepare v2025.01-rc5
2024-12-18fdt: Swap the signature for board_fdt_blob_setup()Simon Glass
This returns a devicetree and updates a parameter with an error code. Swap it, since this fits better with the way U-Boot normally works. It also (more easily) allows leaving the existing pointer unchanged. No yaks were harmed in this change, but there is a very small code-size reduction. For sifive, the OF_BOARD option must be set for the function to be called, so there is no point in checking it again. Also OF_SEPARATE is defined always. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> [trini: Update total_compute] Signed-off-by: Tom Rini <trini@konsulko.com>
2024-12-17ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_topPatrice Chotard
Previously, all LMB marked with LMB_NOMAP (above and below ram_top) are considered as invalid entry in TLB. Since commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") all LMB located above ram_top are now marked LMB_NOOVERWRITE and no more LMB_MAP. This area above ram_top is reserved for OPTEE and must not be cacheable, otherwise this leads to a Panic on some boards (Issue on STM32MP135F-DK). Restore previous behavior by marking invalid entry all TLB above ram_top. Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> cc: Sughosh Ganu <sughosh.ganu@linaro.org> Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
2024-10-16stm32mp: fix name of optee reserved memory nodePatrick Delaunay
In OP-TEE, the "optee_core@" node is reserved, appended in non secure device tree (see mark_tzdram_as_reserved() function under CFG_DT) so this name must be checked in optee_get_reserved_memory(). We keep the check on /reserved-memory/optee@ node to have backward compatibility with STMT32Image booting, when the reserved node is already present in U-Boot or SPL device tree with name "optee@". This patch solves a boot issue on board with OP-TEE for U-Boot compiled with stm32mp15_defconfig and without secure configuration device tree (stm32mp157c-dk2.dts for example). Fixes: 5fe9e0deabb1 ("stm32mp: allow calling optee_get_reserved_memory() from U-Boot") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-10-16ARM: stm32mp: enable data cache after LMB configuration for STM32MP1Patrick Delaunay
Move the stm32mp1 data cache reconfiguration after the lmb init call board_r::initr_lmb to allow parsing of the reserved region with no-map tag. After this patch the DDR is not fully mapped up to arch_early_init_r() call, only the relocation region is mapped, but it is enough for the first board_r initialization phases; later, when arch_early_init_r() is called, the LMB is already initialized and the function lmb_is_reserved_flags() function is functional, this LMB function is called in the weak function dram_bank_mmu_setup() when dcache_enable() is executed. Without this change, as LMB is not initialized when it is used in dram_bank_mmu_setup, the OP-TEE region is mapped cache-able by U-Boot and we have some firewall violation since "LMB memory map global and persistent" series. Fixes: ed17a33fed29 ("lmb: make LMB memory map persistent and global") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-10-16stm32mp: compute ram_top based on the optee base address only for STM32MP1Patrick Delaunay
Reserved memory for OP-TEE is located at end of DDR for STM32MP1 SoC only (STM32MP13 and STM32MP15) and the OP-TEE reserved memory is located at the beginning of DDR for STM32MP25 SoC, before CONFIG_TEXT_BASE and with reserved memory for companion coprocessor. So the ram_top is limited by OP-TEE reserved memory only for STM32MP1 SoC. This patch solves an issue for ram_top value on STM32MP25 SoC because the generic reserved memory management, based on LMB, is no more used before relocation. Fixes: 8242f14a3e6f ("stm32mp: compute ram_top based on the optee base address") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-10-15stm32mp: remove efi_add_known_memory() function definitionSughosh Ganu
The efi_add_known_memory() function for the stm32mp platforms is adding the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled through the LMB module -- the lmb_add_memory() adds this memory to the memory map. Remove the definition of the now superfluous efi_add_known_memory() function. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-11Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"Tom Rini
Simon Glass <sjg@chromium.org> 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-11global: Rename SPL_ to XPL_Simon Glass
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <sjg@chromium.org>
2024-10-11arch: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILDSimon Glass
Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <sjg@chromium.org>
2024-09-30Merge tag 'v2024.10-rc6' into nextTom Rini
Prepare v2024.10-rc6