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 <msucha...@suse.de> > > > > > > > Reviewed-by: Francesco Dolcini <francesco.dolc...@toradex.com> > > > > > > > > > > > > > > > I plan to pick up > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@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-sjo...@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-6c63bad09...@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.delau...@foss.st.com/
Ah, OK, thanks for explaining. -- Tom
signature.asc
Description: PGP signature