On Wed, 11 Dec 2024 at 21:50, Patrice CHOTARD <[email protected]> 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.
I don't think that this patch should be reverted. If the said platform has a reserved memory region above ram_top, I would suggest to either a) move the ram_top on this platform so that the op-tee region gets marked as no-map in the lmb memory map, or b) do not use the lmb memory map to configure the MMU -- can the MMU configuration logic not read the DT to get which regions are to be marked as no-map? As far as the lmb module is concerned, it is being told through this commit to not consider memory above ram_top for allocations, which is not an incorrect thing imo. -sughosh > > Patrice
