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.
