On Fri, 13 Dec 2024 at 00:48, Tom Rini <[email protected]> wrote: > > 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, that won't happen. This is a separate issue from what is being fixed by Sam's series. Patrice, please let me know if the hang is being fixed by the change that I had suggested earlier in this thread. For some reason I don't see a hang on the DK2 board despite the board having a similar memory map of memory being reserved for the op-tee image above ram_top with no-map property. -sughosh > > -- > Tom
