summaryrefslogtreecommitdiff
path: root/arch/arm/mach-stm32mp/dram_init.c
AgeCommit message (Collapse)AuthorFilesLines
2021-09-06stm32mp: Fix board_get_usable_ram_top()Patrice Chotard1-1/+1
When booting in EFI, lib/efi_loader/efi_memory.c calls board_get_usable_ram_top(0) which returns by default gd->ram_base + gd->ram_size which is the top of DDR. In case of OPTEE boot, the top of DDR is currently reserved by OPTEE, board_get_usable_ram_top(0) must return an address outside OPTEE reserved memory. gd->ram_top matches this constraint as it has already been initialized by substracting all DT reserved-memory (included OPTEE memory area). Fixes: 92b611e8b003 ("stm32mp: correctly handle board_get_usable_ram_top(0)") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-08-16stm32mp: correctly handle board_get_usable_ram_top(0)Patrick Delaunay1-0/+3
The function board_get_usable_ram_top can be called after relocation with total_size = 0 to get the uppermost pointer that is valid to access in U-Boot. When total_size = 0, the reserved memory should be not take in account with lmb library and 'gd->ram_base + gd->ram_size' can be used. It is the case today in lib/efi_loader/efi_memory.c:efi_add_known_memory() and this patch avoids that the reserved memory for OP-TEE is not part of the EFI available memory regions. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-06-07stm32mp: Increase the reserved memory in board_get_usable_ram_topPatrick Delaunay1-2/+5
Add 8M for the U-Boot reserved memory (display, fdt, gd, ...) mapped cacheable before relocation. Without this patch the device tree, located before the MALLOC area is not tagged cacheable just after relocation, before mmu reconfiguration. This patch reduces the duration for device tree parsing in lmb_init_and_reserve. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-03-02stm32mp: update MMU config before the relocationPatrick Delaunay1-4/+9
Mark the top of ram, used for relocated U-Boot as a normal memory (cacheable and executable) to avoid permission access issue when U-Boot jumps to this relocated code. When MMU is activated in pre-reloc stage; only the beginning of DDR is marked executable. This patch avoids access issue when DACR is correctly managed. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass1-0/+1
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-01-13arm: stm32mp: migrate trace to log macroPatrick Delaunay1-3/+5
Change debug and pr_ macro to log macro and define LOG_CATEGORY. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-05-19common: Drop log.h from common headerSimon Glass1-0/+1
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-19common: Drop image.h from common headerSimon Glass1-0/+2
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-14board: stm32mp1: reserve memory for OP-TEE in device treePatrick Delaunay1-0/+18
Add reserve memory for OP-TEE in U-Boot and in kernel device tree: - no more reduce the DDR size in "memory" node: CONFIG_SYS_MEM_TOP_HIDE is no more used - U-Boot device-tree defines the needed "reserved-memory" for OP-TEE and U-Boot should not use this reserved memory: board_get_usable_ram_top use lmb lib to found the first free region, the not reserved memory, enough to relocate U-Boot: the needed size of U-Boot is estimated with gd->mon_len + CONFIG_SYS_MALLOC_LEN. - the optee node ("optee@...": firmware with compatible "linaro,optee-tz") and the associated "reserved-memory" are deactivated in kernel device tree when OP-TEE is not detected by U-Boot to prevent kernel issue (memory is reserved but not used, optee driver probe failed). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2018-05-07SPDX: Convert all of our multiple license tags to Linux Kernel styleTom Rini1-2/+1
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have multiple licenses (in these cases, dual license) declared in the SPDX-License-Identifier tag. In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B" as per the Linux Kernel style document. Note that parenthesis are allowed so when they were used before we continue to use them. Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2018-03-19arm: stm32: add new architecture for STM32MP familyPatrick Delaunay1-0/+34
- add new arch stm32mp for STM32 MPU/Soc based on Cortex A - support for stm32mp157 SOC - SPL is used as first boot stage loader - using driver model for all the drivers, even in SPL - all security feature are deactivated (ETZC and TZC) - reused STM32 MCU drivers when it is possible Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>