Commit graph

15 commits

Author SHA1 Message Date
Patrice Chotard
dba8d92a3d stm32mp: dram_init: Get RAM size from DT if no RAM driver found
In case there is no RAM driver retrieve RAM size from DT as fallback.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2023-11-13 10:55:38 +01:00
Heinrich Schuchardt
d768dd8855 common: return type board_get_usable_ram_top
board_get_usable_ram_top() returns a physical address that is stored in
gd->ram_top. The return type of the function should be phys_addr_t like the
current type of gd->ram_top.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-08-15 18:21:17 +02:00
Marek Vasut
a2e0b041d6 arm: stm32mp: Fix board_get_usable_ram_top() again
Do not access gd->ram_size and assume this is actual valid RAM size. Since commit
777aaaa706 ("common/memsize.c: Fix get_effective_memsize() to check for overflow")
the RAM size may be less than gd->ram_size , call get_effective_memsize() to get
the limited value instead.

The aforementioned commit makes STM32MP15xx boards with 1 GiB of DRAM
at 0xc0000000 hang on boot, which is a grave defect.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2023-01-06 11:02:17 +01:00
Pali Rohár
049704f808 board_f: Fix types for board_get_usable_ram_top()
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.

So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.

Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-09-23 15:12:42 -04:00
Patrice Chotard
c8510e397f stm32mp: Fix board_get_usable_ram_top()
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: 92b611e8b0 ("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-09-06 10:00:11 +02:00
Patrick Delaunay
92b611e8b0 stm32mp: correctly handle board_get_usable_ram_top(0)
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-08-16 10:49:35 +02:00
Patrick Delaunay
7dc6068fc1 stm32mp: Increase the reserved memory in board_get_usable_ram_top
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-06-07 10:48:40 -04:00
Patrick Delaunay
1419e5b516 stm32mp: update MMU config before the relocation
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-03-02 15:53:37 -05:00
Simon Glass
401d1c4f5d common: Drop asm/global_data.h from common header
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-02-02 15:33:42 -05:00
Patrick Delaunay
eb653acd63 arm: stm32mp: migrate trace to log macro
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>
2021-01-13 09:52:58 +01:00
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
4d72caa5b9 common: Drop image.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 17:33:33 -04:00
Patrick Delaunay
4a1b975dac board: stm32mp1: reserve memory for OP-TEE in device tree
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>
2020-05-14 09:02:12 +02:00
Tom Rini
4549e789c1 SPDX: Convert all of our multiple license tags to Linux Kernel style
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-05-07 10:24:31 -04:00
Patrick Delaunay
2514c2d0e6 arm: stm32: add new architecture for STM32MP family
- 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>
2018-03-19 16:14:21 -04:00