| Message ID | 1419356091-13121-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Warren |
| Headers | show |
Hi Stephen, On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote: > From: Stephen Warren <swarren@nvidia.com> > > Some systems have so much RAM that the end of RAM is beyond 4GB. An > example would be a Tegra124 system (where RAM starts at 2GB physical) > that has more than 2GB of RAM. > > In this case, we can gd->ram_size to represent the actual RAM size, so > that the actual RAM size is passed to the OS. This is useful if the OS > implements LPAE, and can actually use the "extra" RAM. > > However, U-Boot does not implement LPAE and so must deal with 32-bit > physical addresses. To this end, we enhance board_get_usable_ram_top() to > detect the "over-sized" case, and limit the relocation addres so that it > fits into 32-bits of physical address space. > > Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> > --- > common/board_f.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/common/board_f.c b/common/board_f.c > index 98c9c728ce73..c1ada8d62009 100644 > --- a/common/board_f.c > +++ b/common/board_f.c > @@ -360,6 +360,18 @@ static int setup_fdt(void) > /* Get the top of usable RAM */ > __weak ulong board_get_usable_ram_top(ulong total_size) > { > +#ifdef CONFIG_SYS_SDRAM_BASE > + /* > + * Detect whether we have so much RAM it goes past the end of our > + * 32-bit address space. If so, clip the usable RAM so it doesn't. > + */ > + if (gd->ram_top < CONFIG_SYS_SDRAM_BASE) > + /* > + * Will wrap back to top of 32-bit space when reservations > + * are made. > + */ > + return 0; I wonder whether (ulong)(1ULL << 32) would be more portable, but perhaps it would just be confusing. We can worry about this when we do more 64-bit things. > +#endif > return gd->ram_top; > } > > -- > 1.9.1 > Regards, Simon
On 12/23/2014 01:01 PM, Simon Glass wrote: > Hi Stephen, > > On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote: >> From: Stephen Warren <swarren@nvidia.com> >> >> Some systems have so much RAM that the end of RAM is beyond 4GB. An >> example would be a Tegra124 system (where RAM starts at 2GB physical) >> that has more than 2GB of RAM. >> >> In this case, we can gd->ram_size to represent the actual RAM size, so >> that the actual RAM size is passed to the OS. This is useful if the OS >> implements LPAE, and can actually use the "extra" RAM. >> >> However, U-Boot does not implement LPAE and so must deal with 32-bit >> physical addresses. To this end, we enhance board_get_usable_ram_top() to >> detect the "over-sized" case, and limit the relocation addres so that it >> fits into 32-bits of physical address space. >> >> Signed-off-by: Stephen Warren <swarren@nvidia.com> > > Reviewed-by: Simon Glass <sjg@chromium.org> >> diff --git a/common/board_f.c b/common/board_f.c >> /* Get the top of usable RAM */ >> __weak ulong board_get_usable_ram_top(ulong total_size) >> { >> +#ifdef CONFIG_SYS_SDRAM_BASE >> + /* >> + * Detect whether we have so much RAM it goes past the end of our >> + * 32-bit address space. If so, clip the usable RAM so it doesn't. >> + */ >> + if (gd->ram_top < CONFIG_SYS_SDRAM_BASE) >> + /* >> + * Will wrap back to top of 32-bit space when reservations >> + * are made. >> + */ >> + return 0; > > I wonder whether (ulong)(1ULL << 32) would be more portable, but > perhaps it would just be confusing. We can worry about this when we do > more 64-bit things. I don't think it makes any difference while board_get_usable_ram_top() returns a 32-bit value. If board_get_usable_ram_top() was modified to return a 32-bit value on 32-bit systems and a 64-bit value on 64-bit systems then: The value "0" means "top of addressable address space" (once wrapped from 0 backwards when allocations are made later). The value 1ULL<<32 means 4GB, no matter what the address space size is. That's quite a different thing on 64-bit. We really do want 0 here, not a masked/clipped/overflowed 4GB value, since on 64-bit, if gd->ram_top ended up less than CONFIG_SYS_SDRAM_BASE, we'd have the exact same situation as I'm fixing here on 32-bit, just with much larger numbers; consider a system where RAM starts at (U64_MAX + 1 - 2GB) and RAM is 4GB in size; we get the same wrapping effect. (Admittedly that physical layout would be quite unlikely to happen on 64-bit since presumably no SoC designer would ever set CONFIG_SYS_SDRAM_BASE that high if that much RAM were supported, since that'd require a 64-bit system with >64-bit LPAE, which hopefully is many many years in the future).
Hi Stephen, On 23 December 2014 at 13:22, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 12/23/2014 01:01 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> >> wrote: >>> >>> From: Stephen Warren <swarren@nvidia.com> >>> >>> Some systems have so much RAM that the end of RAM is beyond 4GB. An >>> example would be a Tegra124 system (where RAM starts at 2GB physical) >>> that has more than 2GB of RAM. >>> >>> In this case, we can gd->ram_size to represent the actual RAM size, so >>> that the actual RAM size is passed to the OS. This is useful if the OS >>> implements LPAE, and can actually use the "extra" RAM. >>> >>> However, U-Boot does not implement LPAE and so must deal with 32-bit >>> physical addresses. To this end, we enhance board_get_usable_ram_top() to >>> detect the "over-sized" case, and limit the relocation addres so that it >>> fits into 32-bits of physical address space. >>> >>> Signed-off-by: Stephen Warren <swarren@nvidia.com> >> >> >> Reviewed-by: Simon Glass <sjg@chromium.org> > > >>> diff --git a/common/board_f.c b/common/board_f.c > > >>> /* Get the top of usable RAM */ >>> __weak ulong board_get_usable_ram_top(ulong total_size) >>> { >>> +#ifdef CONFIG_SYS_SDRAM_BASE >>> + /* >>> + * Detect whether we have so much RAM it goes past the end of our >>> + * 32-bit address space. If so, clip the usable RAM so it >>> doesn't. >>> + */ >>> + if (gd->ram_top < CONFIG_SYS_SDRAM_BASE) >>> + /* >>> + * Will wrap back to top of 32-bit space when >>> reservations >>> + * are made. >>> + */ >>> + return 0; >> >> >> I wonder whether (ulong)(1ULL << 32) would be more portable, but >> perhaps it would just be confusing. We can worry about this when we do >> more 64-bit things. > > > I don't think it makes any difference while board_get_usable_ram_top() > returns a 32-bit value. > > If board_get_usable_ram_top() was modified to return a 32-bit value on > 32-bit systems and a 64-bit value on 64-bit systems then: > > The value "0" means "top of addressable address space" (once wrapped from 0 > backwards when allocations are made later). > > The value 1ULL<<32 means 4GB, no matter what the address space size is. > That's quite a different thing on 64-bit. > > We really do want 0 here, not a masked/clipped/overflowed 4GB value, since > on 64-bit, if gd->ram_top ended up less than CONFIG_SYS_SDRAM_BASE, we'd > have the exact same situation as I'm fixing here on 32-bit, just with much > larger numbers; consider a system where RAM starts at (U64_MAX + 1 - 2GB) > and RAM is 4GB in size; we get the same wrapping effect. (Admittedly that > physical layout would be quite unlikely to happen on 64-bit since presumably > no SoC designer would ever set CONFIG_SYS_SDRAM_BASE that high if that much > RAM were supported, since that'd require a 64-bit system with >64-bit LPAE, > which hopefully is many many years in the future). Yes it's best to avoid predicting the future, and what you have looks right for 32-bit. Regards, Simon
On 12/23/2014 10:34 AM, Stephen Warren wrote: > From: Stephen Warren <swarren@nvidia.com> > > Some systems have so much RAM that the end of RAM is beyond 4GB. An > example would be a Tegra124 system (where RAM starts at 2GB physical) > that has more than 2GB of RAM. > > In this case, we can gd->ram_size to represent the actual RAM size, so > that the actual RAM size is passed to the OS. This is useful if the OS > implements LPAE, and can actually use the "extra" RAM. > > However, U-Boot does not implement LPAE and so must deal with 32-bit > physical addresses. To this end, we enhance board_get_usable_ram_top() to > detect the "over-sized" case, and limit the relocation addres so that it > fits into 32-bits of physical address space. TomW, TomR, does this series look good?
On 01/20/2015 08:56 AM, Tom Warren wrote: > I've merged that patch series w/u-boot-tegra/next and /master, done a MAKEALL -s tegra, and rebased against ARM /master and pushed to denx.de. > > Stephen - please test and if it looks OK, I'll prepare a PR. This works great on my Jetson TK1. Thanks. > >> -----Original Message----- >> From: Tom Warren >> Sent: Tuesday, January 20, 2015 8:28 AM >> To: 'Stephen Warren'; u-boot@lists.denx.de; Simon Glass; Stephen Warren >> Cc: Tom Rini >> Subject: RE: [U-Boot] [PATCH 1/3] common: board: support systems with >> where RAM ends beyond 4GB >> >> Sorry, missed this. Yes, looks good to me. I can apply it to u-boot- >> tegra/master, or TomR can take it in to master U-Boot directly. >> >> Tom >> >>> -----Original Message----- >>> From: Stephen Warren [mailto:swarren@wwwdotorg.org] >>> Sent: Monday, January 19, 2015 3:57 PM >>> To: u-boot@lists.denx.de; Simon Glass; Tom Warren; Stephen Warren >>> Cc: Tom Rini >>> Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with >>> where RAM ends beyond 4GB >>> >>> On 12/23/2014 10:34 AM, Stephen Warren wrote: >>>> From: Stephen Warren <swarren@nvidia.com> >>>> >>>> Some systems have so much RAM that the end of RAM is beyond 4GB. >> An >>>> example would be a Tegra124 system (where RAM starts at 2GB >>>> physical) that has more than 2GB of RAM. >>>> >>>> In this case, we can gd->ram_size to represent the actual RAM size, >>>> so that the actual RAM size is passed to the OS. This is useful if >>>> the OS implements LPAE, and can actually use the "extra" RAM. >>>> >>>> However, U-Boot does not implement LPAE and so must deal with 32-bit >>>> physical addresses. To this end, we enhance >>>> board_get_usable_ram_top() to detect the "over-sized" case, and >>>> limit the relocation addres so that it fits into 32-bits of physical address >> space. >>> >>> TomW, TomR, does this series look good? > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- >
diff --git a/common/board_f.c b/common/board_f.c index 98c9c728ce73..c1ada8d62009 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -360,6 +360,18 @@ static int setup_fdt(void) /* Get the top of usable RAM */ __weak ulong board_get_usable_ram_top(ulong total_size) { +#ifdef CONFIG_SYS_SDRAM_BASE + /* + * Detect whether we have so much RAM it goes past the end of our + * 32-bit address space. If so, clip the usable RAM so it doesn't. + */ + if (gd->ram_top < CONFIG_SYS_SDRAM_BASE) + /* + * Will wrap back to top of 32-bit space when reservations + * are made. + */ + return 0; +#endif return gd->ram_top; }