On Tue, 17 Dec 2024 at 16:55, Francesco Dolcini <[email protected]> wrote: > > +Fabio, Marex, Peng, Frieder > > On Tue, Dec 17, 2024 at 08:18:50AM -0300, João Paulo Gonçalves wrote: > > > > > > Okay. Please try changing the value of ram_top to 0x1_0000_0000 > > > instead of 0xFFFF_FFFF. That should work. > > > > > > > Changing ram_top to 0x1_0000_0000 worked: > > > > U-Boot SPL 2025.01-rc4-00025-g100a40dd79f8 (Dec 17 2024 - 08:05:06 -0300) > > DDR configured as dual rank > > WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) > > SEC0: RNG instantiated > > Normal Boot > > Trying to boot from BOOTROM > > Boot Stage: Primary boot > > Find img info 0x4802d400, size 1116 > > Need continue download 1024 > > NOTICE: BL31: v2.6(release):lf_v2.6-g3c1583ba0a > > NOTICE: BL31: Built : 11:00:38, Nov 21 2022 > > > > > > U-Boot 2025.01-rc4-00025-g100a40dd79f8 (Dec 17 2024 - 08:05:06 -0300) > > > > CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz) > > CPU: Industrial temperature grade (-40C to 105C) at 54C > > Reset cause: POR > > DRAM: Ram top: 100000000 > > 8 GiB > > Core: 183 devices, 31 uclasses, devicetree: separate > > WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) > > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > > Loading Environment from MMC... Reading from MMC(2)... OK > > In: serial@30880000 > > Out: serial@30880000 > > Err: serial@30880000 > > Model: Toradex 0070 Verdin iMX8M Plus Quad 8GB WB IT V1.1A > > Serial#: 15207893 > > Carrier: Toradex Dahlia V1.1C, Serial# 11060859 > > SEC0: RNG instantiated > > Setting variant to wifi > > Net: eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME] > > Hit any key to stop autoboot: 0 > > MMC: no card present > > switch to partitions #0, OK > > mmc2(part 0) is current device > > Scanning mmc 2:1... > > Found U-Boot script /boot.scr > > 5974 bytes read in 1 ms (5.7 MiB/s) > > ## Executing script at 50280000 > > Loading DeviceTree: imx8mp-verdin-wifi-dev.dtb > > ... > > Starting kernel ... > > > > The change is shown in the patch below, but I am unsure if this is the > > correct solution. Should ram_top be the last valid address or the upper > > bound? > > > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > > index 9588b8b28bf2..e01774ebc8a4 100644 > > --- a/arch/arm/mach-imx/imx8m/soc.c > > +++ b/arch/arm/mach-imx/imx8m/soc.c > > @@ -362,7 +362,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t > > total_size) > > * space below the 4G address boundary (which is 3GiB big), > > * even when the effective available memory is bigger. > > */ > > - top_addr = clamp_val((u64)PHYS_SDRAM + gd->ram_size, 0, 0xffffffff); > > + top_addr = clamp_val((u64)PHYS_SDRAM + gd->ram_size, 0, > > 0x100000000); > > > > /* > > * rom_pointer[0] stores the TEE memory start address. > > see commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G > boundary"). > > I assume such a change might introduce regressions.
I am not sure which commit you mean, since the above commit is actually restricting the ram_top to 0x8000_0000. This is a corner case of the bank end being above the value of ram_top. With the current values, a single byte at 0xffff_ffff is getting reserved. And this causes the lmb to not reserve the u-boot image region and also causes the future allocations to fail. With the value of ram_top set to 0x1_0000_0000, the single byte reservation does not happen, and the issue is not seen. There is another way that this can be handled in the lmb code, but I want to send that change after this release as we are pretty close to this release. For the meantime, for this release, can you bump up the value of ram_top by 1. I understand that the value of ram_top is one more than the highest address that is to be used on the platform. -sughosh > > Francesco > >
