public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
@ 2026-02-04  2:42 Jeremy Compostella
  2026-02-05 17:50 ` Jeremy Compostella
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Jeremy Compostella @ 2026-02-04  2:42 UTC (permalink / raw)
  To: u-boot; +Cc: Simon Glass

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 <jeremy.compostella@intel.com>
---
 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. */
-- 
2.52.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-04  2:42 [PATCH] x86/coreboot: Exclude memory regions starting above 4GB Jeremy Compostella
@ 2026-02-05 17:50 ` Jeremy Compostella
  2026-02-06  1:50   ` Tom Rini
  2026-02-16 19:39 ` Tom Rini
  2026-02-17 13:32 ` Simon Glass
  2 siblings, 1 reply; 9+ messages in thread
From: Jeremy Compostella @ 2026-02-05 17:50 UTC (permalink / raw)
  To: u-boot; +Cc: Simon Glass

Is there anything more I should be doing? This is a bug fix I would really appreciate seeing merged.

Regards,
Jeremy

Jeremy Compostella <jeremy.compostella@intel.com> 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 <jeremy.compostella@intel.com>
> ---
>  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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-05 17:50 ` Jeremy Compostella
@ 2026-02-06  1:50   ` Tom Rini
  2026-02-06 16:35     ` Jeremy Compostella
  0 siblings, 1 reply; 9+ messages in thread
From: Tom Rini @ 2026-02-06  1:50 UTC (permalink / raw)
  To: Jeremy Compostella; +Cc: u-boot, Simon Glass

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

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.

> 
> Regards,
> Jeremy
> 
> Jeremy Compostella <jeremy.compostella@intel.com> 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 <jeremy.compostella@intel.com>
> > ---
> >  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

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-06  1:50   ` Tom Rini
@ 2026-02-06 16:35     ` Jeremy Compostella
  2026-02-13 23:06       ` Jeremy Compostella
  0 siblings, 1 reply; 9+ messages in thread
From: Jeremy Compostella @ 2026-02-06 16:35 UTC (permalink / raw)
  To: Tom Rini; +Cc: u-boot, Simon Glass

Tom Rini <trini@konsulko.com> 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 <jeremy.compostella@intel.com> 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 <jeremy.compostella@intel.com>
>> > ---
>> >  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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-06 16:35     ` Jeremy Compostella
@ 2026-02-13 23:06       ` Jeremy Compostella
  2026-02-13 23:22         ` Tom Rini
  0 siblings, 1 reply; 9+ messages in thread
From: Jeremy Compostella @ 2026-02-13 23:06 UTC (permalink / raw)
  To: Tom Rini; +Cc: u-boot, Simon Glass

Hi,

Is there any update on this commit?

Jeremy Compostella <jeremy.compostella@intel.com> writes:

> Tom Rini <trini@konsulko.com> 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 <jeremy.compostella@intel.com> 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 <jeremy.compostella@intel.com>
>>> > ---
>>> >  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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-13 23:06       ` Jeremy Compostella
@ 2026-02-13 23:22         ` Tom Rini
  0 siblings, 0 replies; 9+ messages in thread
From: Tom Rini @ 2026-02-13 23:22 UTC (permalink / raw)
  To: Jeremy Compostella; +Cc: u-boot, Simon Glass

[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]

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 <jeremy.compostella@intel.com> writes:
> 
> > Tom Rini <trini@konsulko.com> 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 <jeremy.compostella@intel.com> 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 <jeremy.compostella@intel.com>
> >>> > ---
> >>> >  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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-04  2:42 [PATCH] x86/coreboot: Exclude memory regions starting above 4GB Jeremy Compostella
  2026-02-05 17:50 ` Jeremy Compostella
@ 2026-02-16 19:39 ` Tom Rini
  2026-02-18  2:57   ` Jeremy Compostella
  2026-02-17 13:32 ` Simon Glass
  2 siblings, 1 reply; 9+ messages in thread
From: Tom Rini @ 2026-02-16 19:39 UTC (permalink / raw)
  To: u-boot, Jeremy Compostella; +Cc: Simon Glass

On Tue, 03 Feb 2026 19:42:36 -0700, Jeremy Compostella wrote:

> 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.
> 
> [...]

Applied to u-boot/master, thanks!

[1/1] x86/coreboot: Exclude memory regions starting above 4GB
      commit: 8666b16015d4212facacc514e2eb626f3630dcf0
-- 
Tom



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-04  2:42 [PATCH] x86/coreboot: Exclude memory regions starting above 4GB Jeremy Compostella
  2026-02-05 17:50 ` Jeremy Compostella
  2026-02-16 19:39 ` Tom Rini
@ 2026-02-17 13:32 ` Simon Glass
  2 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2026-02-17 13:32 UTC (permalink / raw)
  To: Jeremy Compostella; +Cc: u-boot

On Tue, 3 Feb 2026 at 19:42, Jeremy Compostella
<jeremy.compostella@intel.com> wrote:
>
> 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 <jeremy.compostella@intel.com>
> ---
>  arch/x86/cpu/coreboot/sdram.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass <simon.glass@canonical.com>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/coreboot: Exclude memory regions starting above 4GB
  2026-02-16 19:39 ` Tom Rini
@ 2026-02-18  2:57   ` Jeremy Compostella
  0 siblings, 0 replies; 9+ messages in thread
From: Jeremy Compostella @ 2026-02-18  2:57 UTC (permalink / raw)
  To: Tom Rini, u-boot; +Cc: Simon Glass

Thank you Tom.

Tom Rini <trini@konsulko.com> writes:

> On Tue, 03 Feb 2026 19:42:36 -0700, Jeremy Compostella wrote:
>
>> 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.
>> 
>> [...]
>
> Applied to u-boot/master, thanks!
>
> [1/1] x86/coreboot: Exclude memory regions starting above 4GB
>       commit: 8666b16015d4212facacc514e2eb626f3630dcf0

-- 
Jeremy
One Emacs to rule them all

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-02-18  4:26 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-04  2:42 [PATCH] x86/coreboot: Exclude memory regions starting above 4GB Jeremy Compostella
2026-02-05 17:50 ` Jeremy Compostella
2026-02-06  1:50   ` Tom Rini
2026-02-06 16:35     ` Jeremy Compostella
2026-02-13 23:06       ` Jeremy Compostella
2026-02-13 23:22         ` Tom Rini
2026-02-16 19:39 ` Tom Rini
2026-02-18  2:57   ` Jeremy Compostella
2026-02-17 13:32 ` Simon Glass

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox