[PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"

[Marek Vasut]

On 8/8/21 4:54 PM, Tom Rini wrote:

[...]

>>> I expect it was not simply because up
>>> until rather recently we didn't have any checks for "don't overwrite
>>> specific areas of memory" other than right before firing off the OS (and
>>> modify whatever memory you want to modify is a feature not a bug).
>>
>> The LMB has been around since forever though ?
> 
> Yes, LMB has been around since the PowerPC device tree days I suspect (I
> didn't dig that far back), but only used outside of the "don't overwrite
> the running U-Boot while we relocate device tree / initrd before booting
> OS" since 2018 or so.

So, are we using LMB for two different things now ?

>> [...]
>>
>>>>> OK, so then there isn't a problem reverting this commit for rcar?
>>>>
>>>> The revert will break the use case where the other CPUs are using memory
>>>> above U-Boot, but have a look at the following branch, it should permit me
>>>> to parametrize the arch_lmb_reserve() better and reserve the right memory
>>>> areas per architecture/mach/board, and even clean the arch_lmb_reserve up
>>>> further:
>>>> https://source.denx.de/u-boot/custodians/u-boot-sh/-/tree/lmb-v1
>>>> So yes, pick the revert and I'll submit the four patches for likely next
>>>> release.
>>>
>>> Thanks for explaining, I'll pick up the revert patch then.
>>>
>>> For your LMB tree, I like the initial approach but looking at
>>> 528915c71762 ("imx: Fix potential lmb memory overwritten by stack") I
>>> think that shows the general "4K is enough for stack we hope" is wrong,
>>> and we should do 16K instead for everyone as the default.  But we can
>>> discuss that more too once you post the whole series which again, I
>>> think is the right direction.
>>
>> The IMX thing is odd indeed and raises a bigger question -- what is the
>> "right" amount of stack to reserve ?
> 
> It's a good question, yes.  And some more details about what exactly the
> NXP folks were doing to hit that would also be nice.

+CC Ye Li.