| Message ID | 20220520043922.1502554-1-judge.packham@gmail.com |
|---|---|
| State | Accepted |
| Commit | 8fd3cf2940464765bc10ae341b525fe0eae8fa87 |
| Delegated to: | Stefan Roese |
| Headers | show |
| Series | arm64: mvebu: handle non-zero base address for RAM | expand |
On 20.05.22 06:39, Chris Packham wrote: > board_get_usable_ram_top() conflated the RAM size with the top address > of RAM. On systems where RAM starts at address 0 these numbers are the > same so it went unnoticed. Update board_get_usable_ram_top() to take > CONFIG_SYS_SDRAM_BASE into account when determining the top address. > > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- > I've got a 64-bit mvebu SoC/board that I plan on submitting in a few > weeks. One of the gotchas with this board is that the physical address > of the RAM starts at 0x2_00000000 (there's some seemingly unmovable I/O > occupying the lower addresses). > > This was one of the earlier issues I hit with porting. I figured it was > independent enough that I could send it out while I'm still working on > the rest of the series. > > arch/arm/mach-mvebu/arm64-common.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > index 5357aa554db4..238edbe6ba56 100644 > --- a/arch/arm/mach-mvebu/arm64-common.c > +++ b/arch/arm/mach-mvebu/arm64-common.c > @@ -28,14 +28,13 @@ DECLARE_GLOBAL_DATA_PTR; > * Currently only 2GiB are mapped for system memory. This is what > * we pass to the U-Boot subsystem here. > */ > -#define USABLE_RAM_SIZE 0x80000000 > +#define USABLE_RAM_SIZE 0x80000000ULL > > ulong board_get_usable_ram_top(ulong total_size) > { > - if (gd->ram_size > USABLE_RAM_SIZE) > - return USABLE_RAM_SIZE; > + unsigned long top = CONFIG_SYS_SDRAM_BASE + min(gd->ram_size, USABLE_RAM_SIZE); > > - return gd->ram_size; > + return (gd->ram_top > top) ? top : gd->ram_top; > } Reviewed-by: Stefan Roese <sr@denx.de> Thanks, Stefan
On 20.05.22 06:39, Chris Packham wrote: > board_get_usable_ram_top() conflated the RAM size with the top address > of RAM. On systems where RAM starts at address 0 these numbers are the > same so it went unnoticed. Update board_get_usable_ram_top() to take > CONFIG_SYS_SDRAM_BASE into account when determining the top address. > > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- > I've got a 64-bit mvebu SoC/board that I plan on submitting in a few > weeks. One of the gotchas with this board is that the physical address > of the RAM starts at 0x2_00000000 (there's some seemingly unmovable I/O > occupying the lower addresses). > > This was one of the earlier issues I hit with porting. I figured it was > independent enough that I could send it out while I'm still working on > the rest of the series. > > arch/arm/mach-mvebu/arm64-common.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) Applied to u-boot-marvell/master Thanks, Stefan > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > index 5357aa554db4..238edbe6ba56 100644 > --- a/arch/arm/mach-mvebu/arm64-common.c > +++ b/arch/arm/mach-mvebu/arm64-common.c > @@ -28,14 +28,13 @@ DECLARE_GLOBAL_DATA_PTR; > * Currently only 2GiB are mapped for system memory. This is what > * we pass to the U-Boot subsystem here. > */ > -#define USABLE_RAM_SIZE 0x80000000 > +#define USABLE_RAM_SIZE 0x80000000ULL > > ulong board_get_usable_ram_top(ulong total_size) > { > - if (gd->ram_size > USABLE_RAM_SIZE) > - return USABLE_RAM_SIZE; > + unsigned long top = CONFIG_SYS_SDRAM_BASE + min(gd->ram_size, USABLE_RAM_SIZE); > > - return gd->ram_size; > + return (gd->ram_top > top) ? top : gd->ram_top; > } > > /* Viele Grüße, Stefan Roese
diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c index 5357aa554db4..238edbe6ba56 100644 --- a/arch/arm/mach-mvebu/arm64-common.c +++ b/arch/arm/mach-mvebu/arm64-common.c @@ -28,14 +28,13 @@ DECLARE_GLOBAL_DATA_PTR; * Currently only 2GiB are mapped for system memory. This is what * we pass to the U-Boot subsystem here. */ -#define USABLE_RAM_SIZE 0x80000000 +#define USABLE_RAM_SIZE 0x80000000ULL ulong board_get_usable_ram_top(ulong total_size) { - if (gd->ram_size > USABLE_RAM_SIZE) - return USABLE_RAM_SIZE; + unsigned long top = CONFIG_SYS_SDRAM_BASE + min(gd->ram_size, USABLE_RAM_SIZE); - return gd->ram_size; + return (gd->ram_top > top) ? top : gd->ram_top; } /*
board_get_usable_ram_top() conflated the RAM size with the top address of RAM. On systems where RAM starts at address 0 these numbers are the same so it went unnoticed. Update board_get_usable_ram_top() to take CONFIG_SYS_SDRAM_BASE into account when determining the top address. Signed-off-by: Chris Packham <judge.packham@gmail.com> --- I've got a 64-bit mvebu SoC/board that I plan on submitting in a few weeks. One of the gotchas with this board is that the physical address of the RAM starts at 0x2_00000000 (there's some seemingly unmovable I/O occupying the lower addresses). This was one of the earlier issues I hit with porting. I figured it was independent enough that I could send it out while I'm still working on the rest of the series. arch/arm/mach-mvebu/arm64-common.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)