On Fri, Feb 13, 2026 at 04:06:58PM -0700, Jeremy Compostella wrote: > Hi, > > Is there any update on this commit?
I'll be putting it in master for v2026.04 sometime next week. > > Jeremy Compostella <[email protected]> writes: > > > Tom Rini <[email protected]> writes: > > > >> On Thu, Feb 05, 2026 at 10:50:24AM -0700, Jeremy Compostella wrote: > >> > >>> Is there anything more I should be doing? This is a bug fix I would > >>> really appreciate seeing merged. > >> > >> It would be nice if someone else reviewed it. It's also been a day since > >> posting. I'll put it in my list to make sure doesn't get lost for the > >> next release, thanks. > > > > Thank you for looking into this. It would indeed help if someone else could > > review it. > > > >>> Jeremy Compostella <[email protected]> writes: > >>> > >>> > This commit updates the RAM region filtering logic in > >>> > board_get_usable_ram_top() to skip any memory regions whose start > >>> > address > >>> > is above 4GB. Previously, only the end address was capped at 4GB, but > >>> > regions entirely above this threshold were still considered. > >>> > > >>> > Typically, the following memory map entries would cause > >>> > board_get_usable_ram_top() to return 0x100000000, which is incorrect. > >>> > > >>> > start=00000000, end=00001000, type=16 > >>> > start=00001000, end=000a0000, type=1 > >>> > start=000a0000, end=000f6000, type=2 > >>> > start=000f6000, end=000f7000, type=16 > >>> > start=000f7000, end=00100000, type=2 > >>> > start=00100000, end=6f170000, type=1 > >>> > start=6f170000, end=70000000, type=16 > >>> > start=70000000, end=80800000, type=2 > >>> > start=e0000000, end=f8000000, type=2 > >>> > start=fa000000, end=fc000000, type=2 > >>> > start=fc800000, end=fc880000, type=2 > >>> > start=fd800000, end=fe800000, type=2 > >>> > start=feb00000, end=feb80000, type=2 > >>> > start=fec00000, end=fed00000, type=2 > >>> > start=fed20000, end=fed80000, type=2 > >>> > start=feda1000, end=feda2000, type=2 > >>> > start=fedc0000, end=fede0000, type=2 > >>> > start=100000000, end=102400000, type=2 > >>> > start=102400000, end=47f800000, type=1 > >>> > start=4000000000, end=4020000000, type=2 > >>> > > >>> > By adding a check to continue the loop if the region's start address > >>> > exceeds 0xffffffffULL, the function now properly ignores regions that > >>> > are > >>> > not usable in 32-bit address space. > >>> > > >>> > Change-Id: I8cbe0281aeea67a2f5bb9f6669456f5c7df9b409 > >>> > Signed-off-by: Jeremy Compostella <[email protected]> > >>> > --- > >>> > arch/x86/cpu/coreboot/sdram.c | 2 ++ > >>> > 1 file changed, 2 insertions(+) > >>> > > >>> > diff --git a/arch/x86/cpu/coreboot/sdram.c > >>> > b/arch/x86/cpu/coreboot/sdram.c > >>> > index 013225f129a..cc1edd7badd 100644 > >>> > --- a/arch/x86/cpu/coreboot/sdram.c > >>> > +++ b/arch/x86/cpu/coreboot/sdram.c > >>> > @@ -42,6 +42,8 @@ phys_addr_t board_get_usable_ram_top(phys_size_t > >>> > total_size) > >>> > continue; > >>> > > >>> > /* Filter memory over 4GB. */ > >>> > + if (start > 0xffffffffULL) > >>> > + continue; > >>> > if (end > 0xffffffffULL) > >>> > end = 0x100000000ULL; > >>> > /* Skip this region if it's too small. */ > >>> > >>> -- > >>> Jeremy > >>> One Emacs to rule them all > > -- > Jeremy > One Emacs to rule them all -- Tom
signature.asc
Description: PGP signature
