[PATCH] lmb: prohibit allocations above ram_top even from same bank

[Patrice CHOTARD]

On 12/13/24 10:54, Sughosh Ganu wrote:
> On Fri, 13 Dec 2024 at 14:44, Patrice CHOTARD
> <patrice.chotard at foss.st.com> wrote:
>>
>>
>>
>> On 12/12/24 20:50, Sughosh Ganu wrote:
>>> On Fri, 13 Dec 2024 at 00:48, Tom Rini <trini at konsulko.com> 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.
>>
>> Hi All
>>
>> I confirm, Sam's series didn't help here as Sughosh said.
>>
>>>
>>> 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.
>>
>> On my side i didn't see the issue on STM32MP157C-DK2 board, but
>> i got it systematically on STM2MP135F-DK.
>>
>> Your suggested patch is fixing the hang observed, i will send a patch.
> 
> Patrice, thanks much for testing and confirming the fix. I suspect
> that the cpu's being used on the two boards might be different. Looks
> like one implementation is speculatively prefetching data from the
> op-tee memory region while other is not, which might explain why this
> is not seen on all ST boards. Just a hunch though :)

That's exactly what we think too ;-)

> 
> -sughosh
> 
>>
>> Thanks all ;-)
>>
>> Patrice
>>
>>
>>>
>>> -sughosh
>>>
>>>>
>>>> --
>>>> Tom