On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: > On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote: > > > Hi Tom, > > > > We currently face an issue on our apalis-imx8 machine, that is not > > able > > to boot with a ramdisk. What happens is that there are all 8 of 8 > > LMBs > > reserved and fdt tries to allocate one more, probably for > > relocation. > > > > I now stumbled on this recent patch and noticed that in my > > understanding > > this is introducing a regression to all the boards you remove > > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > > > For the other question this raises to me is it in general safe to > > just > > increase this limit, let's say to 16? > > > > And since it was quite an effort debugging this issue I thought of > > adding a debug print if the MAX cnt in lmb.c is being hit to ease > > that > > pain for other devs, would you be fine with something like this? > > Right, so with the late in the cycle change to make EFI use LMBs as > well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The > change here switches from a static allocation of a maximum number of > LMBs to dynamically allocating as many of them as needed.
But since you no longer enable LMB_USE_MAX_REGIONS then theres the two limits (default=8) LMB_MEMORY_REGIONS=8 LMB_RESERVED_REGIONS=8 that are limiting the maximum LMB numbers. So in my view this commit does create a regression for all boards you delete `CONFIG_LMB_MAX_REGIONS=64`. At least for me rgn->max is still set to 8 and also after this commit I hit that limit. [1] [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288
