On Wed, Dec 11, 2024 at 05:18:28PM +0100, Patrice CHOTARD wrote:
>
>
> On 12/7/24 16:57, Tom Rini wrote:
> > On Mon, 02 Dec 2024 12:36:24 +0530, Sughosh Ganu wrote:
> >
> >> There are platforms which set the value of ram_top based on certain
> >> restrictions that the platform might have in accessing memory above
> >> ram_top, even when the memory region is in the same DRAM bank. So,
> >> even though the LMB allocator works as expected, when trying to
> >> allocate memory above ram_top, prohibit this by marking all memory
> >> above ram_top as reserved, even if the said memory region is from the
> >> same bank.
> >>
> >> [...]
> >
> > Applied to u-boot/master, thanks!
> >
> Hello
>
> This patch is breaking the boot on STM32MP135F-DK.
>
> On this platform, we got an area above gd->ram_top,
> this area, reserved for OPTEE, is tagged with LMB_NOMAP in
> boot_fdt_add_mem_rsv_regions().
>
> Since this commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even
> from same bank"),
> this area is no more tagged as LMB_NOMAP, because it's previously been
> tagged with LMB_NOOVERWRITE in lmb_add_memory().
>
> By not being tagged LMB_NOMAP, the MMU configuration is impacted and leads to
> a panic.
>
> I suggest to revert this patch.Hi Patrice. Can you please re-test current top of tree? I believe Sam's series should resolve this problem as well. Thanks! -- Tom
signature.asc
Description: PGP signature

