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

Attachment: signature.asc
Description: PGP signature

Reply via email to