[PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS

Thu Feb 23 23:34:25 CET 2023

On Thu, Feb 23, 2023 at 10:24:44AM +0100, Patrick DELAUNAY wrote:
> Hi,
> 
> On 2/17/23 10:28, Michal Suchánek wrote:
> > Hello,
> > 
> > On Sun, Feb 12, 2023 at 06:45:36PM -0500, Tom Rini wrote:
> > > On Wed, Feb 08, 2023 at 02:50:16PM -0500, Tom Rini wrote:
> > > > On Wed, Feb 08, 2023 at 08:11:34PM +0100, Michal Suchánek wrote:
> > > > > Hello,
> > > > > 
> > > > > On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> > > > > > On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > > > > > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > > > > > > It is reported that in some configurations it is not possible to boot
> > > > > > > > > because u-boot runs out of lmbs.
> > > > > > > > > 
> > > > > > > > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> > > > > > > > > hence is likely the cause of the lmb overflow.
> > > > > > > > > 
> > > > > > > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > > > > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > > > > > > Signed-off-by: Michal Suchanek <msuchanek at suse.de>
> > > > > > > Reviewed-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > > > > > > 
> > > > > > > > I plan to pick up
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-trini@konsulko.com/
> > > > > > > > as the alternative fix for this issue and would suggest that any distro
> > > > > > > > hitting the problem on v2023.01 apply the above instead of increasing
> > > > > > > > the limit.
> > > > > > > Tom, my understanding is that you plan to merge this or an equivalent
> > > > > > > change, correct? Otherwise I would need to send some more patches to
> > > > > > > update a few board defconfig that are affected by this specific issue.
> > > > > > Yes, I was hoping to push the equivalent of this patch a few hours ago,
> > > > > > along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
> > > > > > scale past 8, and I just now figured out what that should look like
> > > > > > instead, I believe.
> > > > > reportedly neither fixes the problem in all cases, and raising
> > > > > CONFIG_LMB_RESERVED_REGIONS is required.
> > > > > 
> > > > > Looks like the mechanism to add regions above the default number does
> > > > > not work as intended.
> > > > > 
> > > > > The test is to boot rPi 4 from USB directly with recent firmware.
> > > > Well, given 0089affee275 ("configs: stm32mp15: increase the number of
> > > > reserved memory region in lmb") I guess this has been run in to before,
> > > > but not resolved more generically.
> > > I wonder if
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230212150706.2967007-2-sjoerd@collabora.com/
> > > is what will finish dealing with these issues, even the ones that had
> > > perhaps shown up before and been addressed in the commit I mentioned
> > > above?
> > Looks like this together with raising the maximum number of regions
> > works, that is v2023.04-rc2 should be fixed.
> > 
> > Thanks
> > 
> > Michal
> 
> 
> For STM32MP15x platform with have the same issue when the number of reserved
> regions increased in Linux device tree.
> 
> 
> I try to increase the region by default with CONFIG_LMB_MAX_REGIONS,
> 
> but my patch increase the used RAM size for some platform (with compilation
> issue).
> 
> 
> For Tom ask me to propose a backward compatible configuration
> 
> https://lore.kernel.org/all/18550712-c32d-e08b-c38e-6c63bad09009@foss.st.com/
> 
> => CONFIG_USE_LMB_MAX_REGIONS
> 
> 
> Moreover, if you increased CONFIG_LMB_MAX_REGIONS
> 
> the same number of region (N) is used for reserved regions (N) and for 
> memory region (N)
> 
> => the total size used = 2 * N * size of each memory region descriptor.
> 
> 
> But for most of case only the number reserved regions need to be increased
> to parse the device tree.
> 
> 
> With my patch the number of regions are statically managed by  2 array
> independently
> 
> - reserved regions = CONFIG_LMB_RESERVED_REGIONS
> 
> - memory region = CONFIG_LMB_MEMORY_REGIONS
> 
> And the total number of region (size of struct in memory) =
> 
> CONFIG_LMB_RESERVED_REGIONS + CONFIG_LMB_MEMORY_REGIONS
> 
> 
> I think a good solution to have by default, if you want managed more
> reserved memory by default in U-Boot for all platform:
> 
> 
> => LMB_USE_MAX_REGIONS=n  instead of 'y' today
> 
> => LMB_MEMORY_REGIONS=8
> 
> => LMB_RESERVED_REGIONS=16 or 32 instead of 8 today by default
> 
> 
> And change the defconfig for the size constraint platforms
> 
> to use the previous behavior with LMB_USE_MAX_REGIONS=y.
> 
> 
> NB: I define the default value with 8 to keep the previous limit and
> 
>        I just increase the number of region for the STM32MP platform:
> 
> 
> configs/stm32mp15_defconfig:170:CONFIG_LMB_RESERVED_REGIONS=16
> configs/stm32mp15_trusted_defconfig:170:CONFIG_LMB_RESERVED_REGIONS=16
> configs/stm32mp13_defconfig:81:CONFIG_LMB_RESERVED_REGIONS=16
> configs/stm32mp15_basic_defconfig:194:CONFIG_LMB_RESERVED_REGIONS=16
> 
> I use the default value for CONFIG_LMB_MEMORY_REGIONS =8
> 
> 
> Reference = https://lore.kernel.org/all/20210310091632.17103-1-patrick.delaunay@foss.st.com/

Ah, OK, thanks for explaining.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230223/612d460f/attachment.sig>