* [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB
@ 2021-01-21 15:00 Bin Meng
2021-01-21 15:00 ` [PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit Bin Meng
` (6 more replies)
0 siblings, 7 replies; 16+ messages in thread
From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw)
To: u-boot
When testing QEMU RISC-V 'virt' machine with a 2 GiB memory
configuration, it was discovered gd->ram_top is assigned to
value zero in setup_dest_addr().
While 2 GiB QEMU RISC-V 'virt' happens to work with U-Boot today,
increasing more memory doesn't make a bootable system. There are
various places in U-Boot that prevents such from working.
While this is seen and tested on RISC-V, it's not RISC-V centric,
but a generic issue that may affect all architectures.
Bin Meng (7):
riscv: Adjust board_get_usable_ram_top() for 32-bit
global_data.h: Change ram_top type to phys_addr_t
serial: sifive: Cast dev_read_addr() with uintptr_t
fdtdec: Cast prior_stage_fdt_address with uintptr_t
riscv: Change phys_addr_t and phys_size_t to 64-bit
bdinfo: Rename function names to be clearer
bdinfo: Change to use bdinfo_print_num_ll() where the number could be
64-bit
arch/arm/lib/bdinfo.c | 16 +++++-----
arch/m68k/lib/bdinfo.c | 2 +-
arch/powerpc/lib/bdinfo.c | 4 +--
arch/riscv/cpu/fu540/dram.c | 7 ++---
arch/riscv/cpu/generic/dram.c | 7 ++---
arch/riscv/include/asm/types.h | 4 +--
cmd/bdinfo.c | 52 +++++++++++++++----------------
drivers/serial/serial_sifive.c | 2 +-
include/asm-generic/global_data.h | 2 +-
include/init.h | 3 +-
lib/fdtdec.c | 2 +-
11 files changed, 50 insertions(+), 51 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-21 15:00 ` [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t Bin Meng ` (5 subsequent siblings) 6 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> When testing QEMU RISC-V 'virt' machine with a 2 GiB memory configuration, it was discovered gd->ram_top is assigned to value zero in setup_dest_addr(). While gd->ram_top should not be declared as type `unsigned long`, which will be updated in a future patch, the current logic in board_get_usable_ram_top() can be updated to cover both 64-bit and 32-bit RISC-V. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- arch/riscv/cpu/fu540/dram.c | 7 +++---- arch/riscv/cpu/generic/dram.c | 7 +++---- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/riscv/cpu/fu540/dram.c b/arch/riscv/cpu/fu540/dram.c index 1dc77efeca..259da65a54 100644 --- a/arch/riscv/cpu/fu540/dram.c +++ b/arch/riscv/cpu/fu540/dram.c @@ -22,7 +22,6 @@ int dram_init_banksize(void) ulong board_get_usable_ram_top(ulong total_size) { -#ifdef CONFIG_64BIT /* * Ensure that we run from first 4GB so that all * addresses used by U-Boot are 32bit addresses. @@ -31,8 +30,8 @@ ulong board_get_usable_ram_top(ulong total_size) * devices work fine because DMA mapping APIs will * provide 32bit DMA addresses only. */ - if (gd->ram_top > SZ_4G) - return SZ_4G; -#endif + if (gd->ram_top >= SZ_4G) + return SZ_4G - 1; + return gd->ram_top; } diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c index 1dc77efeca..259da65a54 100644 --- a/arch/riscv/cpu/generic/dram.c +++ b/arch/riscv/cpu/generic/dram.c @@ -22,7 +22,6 @@ int dram_init_banksize(void) ulong board_get_usable_ram_top(ulong total_size) { -#ifdef CONFIG_64BIT /* * Ensure that we run from first 4GB so that all * addresses used by U-Boot are 32bit addresses. @@ -31,8 +30,8 @@ ulong board_get_usable_ram_top(ulong total_size) * devices work fine because DMA mapping APIs will * provide 32bit DMA addresses only. */ - if (gd->ram_top > SZ_4G) - return SZ_4G; -#endif + if (gd->ram_top >= SZ_4G) + return SZ_4G - 1; + return gd->ram_top; } -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng 2021-01-21 15:00 ` [PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-24 2:03 ` Simon Glass 2021-01-21 15:00 ` [PATCH 3/7] serial: sifive: Cast dev_read_addr() with uintptr_t Bin Meng ` (4 subsequent siblings) 6 siblings, 1 reply; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> It's possible to have ram_top above 4 GiB in a 32-bit system, hence we need to declare ram_top as `phys_addr_t`. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- include/asm-generic/global_data.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index 19f70393b4..c19b32a82d 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -147,7 +147,7 @@ struct global_data { /** * @ram_top: top address of RAM used by U-Boot */ - unsigned long ram_top; + phys_addr_t ram_top; /** * @relocaddr: start address of U-Boot in RAM * -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-21 15:00 ` [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t Bin Meng @ 2021-01-24 2:03 ` Simon Glass 2021-01-29 17:47 ` Simon Glass 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2021-01-24 2:03 UTC (permalink / raw) To: u-boot On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > From: Bin Meng <bin.meng@windriver.com> > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > we need to declare ram_top as `phys_addr_t`. > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > --- > > include/asm-generic/global_data.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-24 2:03 ` Simon Glass @ 2021-01-29 17:47 ` Simon Glass 2021-01-30 10:13 ` Bin Meng 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2021-01-29 17:47 UTC (permalink / raw) To: u-boot Hi Bin, On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > From: Bin Meng <bin.meng@windriver.com> > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > we need to declare ram_top as `phys_addr_t`. > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > --- > > > > include/asm-generic/global_data.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass <sjg@chromium.org> This patch causes build warnings...can you please take a look? https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 Regards, Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-29 17:47 ` Simon Glass @ 2021-01-30 10:13 ` Bin Meng 2021-01-30 16:24 ` Simon Glass 0 siblings, 1 reply; 16+ messages in thread From: Bin Meng @ 2021-01-30 10:13 UTC (permalink / raw) To: u-boot Hi Simon, On Sat, Jan 30, 2021 at 1:48 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > > we need to declare ram_top as `phys_addr_t`. > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > > --- > > > > > > include/asm-generic/global_data.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > This patch causes build warnings...can you please take a look? > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 That's strange. I did run Azure before I posted this series, and Azure did not report any failure. See https://dev.azure.com/bmeng/GitHub/_build/results?buildId=307&view=results Did you apply all patches in this series? Regards, Bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-30 10:13 ` Bin Meng @ 2021-01-30 16:24 ` Simon Glass 2021-01-31 3:40 ` Bin Meng 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2021-01-30 16:24 UTC (permalink / raw) To: u-boot Hi Bin, On Sat, 30 Jan 2021 at 03:14, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Sat, Jan 30, 2021 at 1:48 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > > > > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > > > we need to declare ram_top as `phys_addr_t`. > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > > > --- > > > > > > > > include/asm-generic/global_data.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > This patch causes build warnings...can you please take a look? > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 > > That's strange. I did run Azure before I posted this series, and Azure > did not report any failure. > > See https://dev.azure.com/bmeng/GitHub/_build/results?buildId=307&view=results > > Did you apply all patches in this series? At that link you can see the commit I built...I don't know how to see the list of previous commits in the web interface but I suppose you could fetch it and look. Re the warning, it is there... see here: https://dev.azure.com/bmeng/f9017223-94f4-4916-a888-4cac5e17223f/_apis/build/builds/307/logs/603 Regards, Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-30 16:24 ` Simon Glass @ 2021-01-31 3:40 ` Bin Meng 2021-01-31 3:44 ` Simon Glass 0 siblings, 1 reply; 16+ messages in thread From: Bin Meng @ 2021-01-31 3:40 UTC (permalink / raw) To: u-boot Hi Simon, On Sun, Jan 31, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Sat, 30 Jan 2021 at 03:14, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Simon, > > > > On Sat, Jan 30, 2021 at 1:48 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Bin, > > > > > > On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > > > > we need to declare ram_top as `phys_addr_t`. > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > > > > --- > > > > > > > > > > include/asm-generic/global_data.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > This patch causes build warnings...can you please take a look? > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 > > > > That's strange. I did run Azure before I posted this series, and Azure > > did not report any failure. > > > > See https://dev.azure.com/bmeng/GitHub/_build/results?buildId=307&view=results > > > > Did you apply all patches in this series? > > At that link you can see the commit I built...I don't know how to see > the list of previous commits in the web interface but I suppose you > could fetch it and look. > > Re the warning, it is there... see here: > > https://dev.azure.com/bmeng/f9017223-94f4-4916-a888-4cac5e17223f/_apis/build/builds/307/logs/603 > Strange, I wonder why Azure does not report it but gitlab reports it .. Regards, Bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-31 3:40 ` Bin Meng @ 2021-01-31 3:44 ` Simon Glass 2021-01-31 8:35 ` Bin Meng 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2021-01-31 3:44 UTC (permalink / raw) To: u-boot Hi Bin, On Sat, 30 Jan 2021 at 20:40, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Sun, Jan 31, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Sat, 30 Jan 2021 at 03:14, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > Hi Simon, > > > > > > On Sat, Jan 30, 2021 at 1:48 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > > > > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > > > > > we need to declare ram_top as `phys_addr_t`. > > > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > > > > > --- > > > > > > > > > > > > include/asm-generic/global_data.h | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > > > This patch causes build warnings...can you please take a look? > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 > > > > > > That's strange. I did run Azure before I posted this series, and Azure > > > did not report any failure. > > > > > > See https://dev.azure.com/bmeng/GitHub/_build/results?buildId=307&view=results > > > > > > Did you apply all patches in this series? > > > > At that link you can see the commit I built...I don't know how to see > > the list of previous commits in the web interface but I suppose you > > could fetch it and look. > > > > Re the warning, it is there... see here: > > > > https://dev.azure.com/bmeng/f9017223-94f4-4916-a888-4cac5e17223f/_apis/build/builds/307/logs/603 > > > > Strange, I wonder why Azure does not report it but gitlab reports it .. I wonder if gitlab uses buildman -E but Azure does not? Regards, Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t 2021-01-31 3:44 ` Simon Glass @ 2021-01-31 8:35 ` Bin Meng 0 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-31 8:35 UTC (permalink / raw) To: u-boot Hi Simon, On Sun, Jan 31, 2021 at 11:45 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Sat, 30 Jan 2021 at 20:40, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Simon, > > > > On Sun, Jan 31, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Bin, > > > > > > On Sat, 30 Jan 2021 at 03:14, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sat, Jan 30, 2021 at 1:48 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > On Sat, 23 Jan 2021 at 19:03, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > > > On Thu, 21 Jan 2021 at 08:00, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > > > > > > > > > It's possible to have ram_top above 4 GiB in a 32-bit system, hence > > > > > > > we need to declare ram_top as `phys_addr_t`. > > > > > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > > > > > > > --- > > > > > > > > > > > > > > include/asm-generic/global_data.h | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > > > > > This patch causes build warnings...can you please take a look? > > > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/213226 > > > > > > > > That's strange. I did run Azure before I posted this series, and Azure > > > > did not report any failure. > > > > > > > > See https://dev.azure.com/bmeng/GitHub/_build/results?buildId=307&view=results > > > > > > > > Did you apply all patches in this series? > > > > > > At that link you can see the commit I built...I don't know how to see > > > the list of previous commits in the web interface but I suppose you > > > could fetch it and look. > > > > > > Re the warning, it is there... see here: > > > > > > https://dev.azure.com/bmeng/f9017223-94f4-4916-a888-4cac5e17223f/_apis/build/builds/307/logs/603 > > > > > > > Strange, I wonder why Azure does not report it but gitlab reports it .. > > I wonder if gitlab uses buildman -E but Azure does not? Yes, caused by commit dd5c954e917b937f85a2f8bfd79e0c9bce372985. I will send a patch to correct this. Regards, Bin ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 3/7] serial: sifive: Cast dev_read_addr() with uintptr_t 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng 2021-01-21 15:00 ` [PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit Bin Meng 2021-01-21 15:00 ` [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-21 15:00 ` [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address " Bin Meng ` (3 subsequent siblings) 6 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> dev_read_addr() returns fdt_addr_t which is now a 64-bit address. In a 32-bit build, this causes the following warning seen when building serial_sifive.c: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Cast the return value with uintptr_t. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- drivers/serial/serial_sifive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c index d26fe7e770..97bf20c967 100644 --- a/drivers/serial/serial_sifive.c +++ b/drivers/serial/serial_sifive.c @@ -178,7 +178,7 @@ static int sifive_serial_of_to_plat(struct udevice *dev) { struct sifive_uart_plat *plat = dev_get_plat(dev); - plat->regs = (struct uart_sifive *)dev_read_addr(dev); + plat->regs = (struct uart_sifive *)(uintptr_t)dev_read_addr(dev); if (IS_ERR(plat->regs)) return PTR_ERR(plat->regs); -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address with uintptr_t 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng ` (2 preceding siblings ...) 2021-01-21 15:00 ` [PATCH 3/7] serial: sifive: Cast dev_read_addr() with uintptr_t Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-24 2:03 ` Simon Glass 2021-01-21 15:00 ` [PATCH 5/7] riscv: Change phys_addr_t and phys_size_t to 64-bit Bin Meng ` (2 subsequent siblings) 6 siblings, 1 reply; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> At present prior_stage_fdt_address is declared as phys_addr_t. On a 32-bit platform where phys_addr_t can be 64-bit, assigning its value to gd->fdt_blob which is a pointer, can cause warnings. Cast it to uintptr_t before the assignment. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- lib/fdtdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 0ab7105fef..4abc7e00fd 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1571,7 +1571,7 @@ int fdtdec_setup(void) return -1; } # elif defined(CONFIG_OF_PRIOR_STAGE) - gd->fdt_blob = (void *)prior_stage_fdt_address; + gd->fdt_blob = (void *)(uintptr_t)prior_stage_fdt_address; # endif # ifndef CONFIG_SPL_BUILD /* Allow the early environment to override the fdt address */ -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address with uintptr_t 2021-01-21 15:00 ` [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address " Bin Meng @ 2021-01-24 2:03 ` Simon Glass 0 siblings, 0 replies; 16+ messages in thread From: Simon Glass @ 2021-01-24 2:03 UTC (permalink / raw) To: u-boot On Thu, 21 Jan 2021 at 08:01, Bin Meng <bmeng.cn@gmail.com> wrote: > > From: Bin Meng <bin.meng@windriver.com> > > At present prior_stage_fdt_address is declared as phys_addr_t. On > a 32-bit platform where phys_addr_t can be 64-bit, assigning its > value to gd->fdt_blob which is a pointer, can cause warnings. > > Cast it to uintptr_t before the assignment. > > Signed-off-by: Bin Meng <bin.meng@windriver.com> > --- > > lib/fdtdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org> The prior-stage stuff should be modified to use SPL_HANDOFF ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 5/7] riscv: Change phys_addr_t and phys_size_t to 64-bit 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng ` (3 preceding siblings ...) 2021-01-21 15:00 ` [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address " Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-21 15:00 ` [PATCH 6/7] bdinfo: Rename function names to be clearer Bin Meng 2021-01-21 15:00 ` [PATCH 7/7] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit Bin Meng 6 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> phys_addr_t and phys_size_t are currently defined as `unsigned long`, but RV32 supports 34-bit physical address, hence both phys_addr_t and phys_size_t should be defined to 64-bit using `unsigned long long`. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- arch/riscv/include/asm/types.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/types.h b/arch/riscv/include/asm/types.h index b800b2d221..49f7a5d6b3 100644 --- a/arch/riscv/include/asm/types.h +++ b/arch/riscv/include/asm/types.h @@ -35,8 +35,8 @@ typedef u64 dma_addr_t; typedef u32 dma_addr_t; #endif -typedef unsigned long phys_addr_t; -typedef unsigned long phys_size_t; +typedef unsigned long long phys_addr_t; +typedef unsigned long long phys_size_t; #endif /* __KERNEL__ */ -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 6/7] bdinfo: Rename function names to be clearer 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng ` (4 preceding siblings ...) 2021-01-21 15:00 ` [PATCH 5/7] riscv: Change phys_addr_t and phys_size_t to 64-bit Bin Meng @ 2021-01-21 15:00 ` Bin Meng 2021-01-21 15:00 ` [PATCH 7/7] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit Bin Meng 6 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> At present we have bdinfo_print_num() to print unsigned long numbers. We also have print_phys_addr() which accept numbers that might be 64-bit on a 32-bit platform. Rename these 2 functions to be clearer: bdinfo_print_num() => bdinfo_print_num_l() print_phys_addr() => bdinfo_print_num_ll() While we are here, make bdinfo_print_num_ll() public so that it can be used outside cmd/bdinfo.c in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- arch/arm/lib/bdinfo.c | 16 ++++++------ arch/m68k/lib/bdinfo.c | 2 +- arch/powerpc/lib/bdinfo.c | 4 +-- cmd/bdinfo.c | 52 +++++++++++++++++++-------------------- include/init.h | 3 ++- 5 files changed, 39 insertions(+), 38 deletions(-) diff --git a/arch/arm/lib/bdinfo.c b/arch/arm/lib/bdinfo.c index 25bc6e80f4..4a98cb7ef5 100644 --- a/arch/arm/lib/bdinfo.c +++ b/arch/arm/lib/bdinfo.c @@ -15,23 +15,23 @@ void arch_print_bdinfo(void) { struct bd_info *bd = gd->bd; - bdinfo_print_num("arch_number", bd->bi_arch_number); + bdinfo_print_num_l("arch_number", bd->bi_arch_number); #ifdef CONFIG_SYS_MEM_RESERVE_SECURE if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) { - bdinfo_print_num("Secure ram", - gd->arch.secure_ram & - MEM_RESERVE_SECURE_ADDR_MASK); + bdinfo_print_num_l("Secure ram", + gd->arch.secure_ram & + MEM_RESERVE_SECURE_ADDR_MASK); } #endif #ifdef CONFIG_RESV_RAM if (gd->arch.resv_ram) - bdinfo_print_num("Reserved ram", gd->arch.resv_ram); + bdinfo_print_num_l("Reserved ram", gd->arch.resv_ram); #endif #if !(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) - bdinfo_print_num("TLB addr", gd->arch.tlb_addr); + bdinfo_print_num_l("TLB addr", gd->arch.tlb_addr); #endif - bdinfo_print_num("irq_sp", gd->irq_sp); /* irq stack pointer */ - bdinfo_print_num("sp start ", gd->start_addr_sp); + bdinfo_print_num_l("irq_sp", gd->irq_sp); /* irq stack pointer */ + bdinfo_print_num_l("sp start ", gd->start_addr_sp); /* * TODO: Currently only support for davinci SOC's is added. * Remove this check once all the board implement this. diff --git a/arch/m68k/lib/bdinfo.c b/arch/m68k/lib/bdinfo.c index 404e5f19ed..92ea175202 100644 --- a/arch/m68k/lib/bdinfo.c +++ b/arch/m68k/lib/bdinfo.c @@ -38,7 +38,7 @@ void arch_print_bdinfo(void) bdinfo_print_mhz("busfreq", bd->bi_busfreq); #if defined(CONFIG_SYS_MBAR) - bdinfo_print_num("mbar", bd->bi_mbar_base); + bdinfo_print_num_l("mbar", bd->bi_mbar_base); #endif bdinfo_print_mhz("cpufreq", bd->bi_intfreq); if (IS_ENABLED(CONFIG_PCI)) diff --git a/arch/powerpc/lib/bdinfo.c b/arch/powerpc/lib/bdinfo.c index 36c9c99ee6..b14e75b68a 100644 --- a/arch/powerpc/lib/bdinfo.c +++ b/arch/powerpc/lib/bdinfo.c @@ -47,9 +47,9 @@ void arch_print_bdinfo(void) bdinfo_print_mhz("busfreq", bd->bi_busfreq); #if defined(CONFIG_MPC8xx) || defined(CONFIG_E500) - bdinfo_print_num("immr_base", bd->bi_immr_base); + bdinfo_print_num_l("immr_base", bd->bi_immr_base); #endif - bdinfo_print_num("bootflags", bd->bi_bootflags); + bdinfo_print_num_l("bootflags", bd->bi_bootflags); bdinfo_print_mhz("intfreq", bd->bi_intfreq); #ifdef CONFIG_ENABLE_36BIT_PHYS if (IS_ENABLED(CONFIG_PHYS_64BIT)) diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index 8d8daa6336..996546faf3 100644 --- a/cmd/bdinfo.c +++ b/cmd/bdinfo.c @@ -18,11 +18,16 @@ DECLARE_GLOBAL_DATA_PTR; -void bdinfo_print_num(const char *name, ulong value) +void bdinfo_print_num_l(const char *name, ulong value) { printf("%-12s= 0x%0*lx\n", name, 2 * (int)sizeof(value), value); } +void bdinfo_print_num_ll(const char *name, unsigned long long value) +{ + printf("%-12s= 0x%.*llx\n", name, 2 * (int)sizeof(ulong), value); +} + static void print_eth(int idx) { char name[10], *val; @@ -36,12 +41,6 @@ static void print_eth(int idx) printf("%-12s= %s\n", name, val); } -static void print_phys_addr(const char *name, phys_addr_t value) -{ - printf("%-12s= 0x%.*llx\n", name, 2 * (int)sizeof(ulong), - (unsigned long long)value); -} - void bdinfo_print_mhz(const char *name, unsigned long hz) { char buf[32]; @@ -55,9 +54,9 @@ static void print_bi_dram(const struct bd_info *bd) for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { if (bd->bi_dram[i].size) { - bdinfo_print_num("DRAM bank", i); - bdinfo_print_num("-> start", bd->bi_dram[i].start); - bdinfo_print_num("-> size", bd->bi_dram[i].size); + bdinfo_print_num_l("DRAM bank", i); + bdinfo_print_num_l("-> start", bd->bi_dram[i].start); + bdinfo_print_num_l("-> size", bd->bi_dram[i].size); } } } @@ -77,9 +76,10 @@ static void show_video_info(void) if (device_active(dev)) { struct video_priv *upriv = dev_get_uclass_priv(dev); - print_phys_addr("FB base", (ulong)upriv->fb); + bdinfo_print_num_ll("FB base", (ulong)upriv->fb); if (upriv->copy_fb) - print_phys_addr("FB copy", (ulong)upriv->copy_fb); + bdinfo_print_num_ll("FB copy", + (ulong)upriv->copy_fb); printf("%-12s= %dx%dx%d\n", "FB size", upriv->xsize, upriv->ysize, 1 << upriv->bpix); } @@ -91,36 +91,36 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) struct bd_info *bd = gd->bd; #ifdef DEBUG - bdinfo_print_num("bd address", (ulong)bd); + bdinfo_print_num_l("bd address", (ulong)bd); #endif - bdinfo_print_num("boot_params", (ulong)bd->bi_boot_params); + bdinfo_print_num_l("boot_params", (ulong)bd->bi_boot_params); print_bi_dram(bd); if (IS_ENABLED(CONFIG_SYS_HAS_SRAM)) { - bdinfo_print_num("sramstart", (ulong)bd->bi_sramstart); - bdinfo_print_num("sramsize", (ulong)bd->bi_sramsize); + bdinfo_print_num_l("sramstart", (ulong)bd->bi_sramstart); + bdinfo_print_num_l("sramsize", (ulong)bd->bi_sramsize); } - bdinfo_print_num("flashstart", (ulong)bd->bi_flashstart); - bdinfo_print_num("flashsize", (ulong)bd->bi_flashsize); - bdinfo_print_num("flashoffset", (ulong)bd->bi_flashoffset); + bdinfo_print_num_l("flashstart", (ulong)bd->bi_flashstart); + bdinfo_print_num_l("flashsize", (ulong)bd->bi_flashsize); + bdinfo_print_num_l("flashoffset", (ulong)bd->bi_flashoffset); printf("baudrate = %u bps\n", gd->baudrate); - bdinfo_print_num("relocaddr", gd->relocaddr); - bdinfo_print_num("reloc off", gd->reloc_off); + bdinfo_print_num_l("relocaddr", gd->relocaddr); + bdinfo_print_num_l("reloc off", gd->reloc_off); printf("%-12s= %u-bit\n", "Build", (uint)sizeof(void *) * 8); if (IS_ENABLED(CONFIG_CMD_NET)) { printf("current eth = %s\n", eth_get_name()); print_eth(0); printf("IP addr = %s\n", env_get("ipaddr")); } - bdinfo_print_num("fdt_blob", (ulong)gd->fdt_blob); - bdinfo_print_num("new_fdt", (ulong)gd->new_fdt); - bdinfo_print_num("fdt_size", (ulong)gd->fdt_size); + bdinfo_print_num_l("fdt_blob", (ulong)gd->fdt_blob); + bdinfo_print_num_l("new_fdt", (ulong)gd->new_fdt); + bdinfo_print_num_l("fdt_size", (ulong)gd->fdt_size); if (IS_ENABLED(CONFIG_DM_VIDEO)) show_video_info(); #if defined(CONFIG_LCD) || defined(CONFIG_VIDEO) - bdinfo_print_num("FB base ", gd->fb_base); + bdinfo_print_num_l("FB base ", gd->fb_base); #endif #if CONFIG_IS_ENABLED(MULTI_DTB_FIT) - bdinfo_print_num("multi_dtb_fit", (ulong)gd->multi_dtb_fit); + bdinfo_print_num_l("multi_dtb_fit", (ulong)gd->multi_dtb_fit); #endif if (gd->fdt_blob) { struct lmb lmb; diff --git a/include/init.h b/include/init.h index 980be27993..88f84599e9 100644 --- a/include/init.h +++ b/include/init.h @@ -326,7 +326,8 @@ void relocate_code(ulong start_addr_sp, struct global_data *new_gd, #endif /* Print a numeric value (for use in arch_print_bdinfo()) */ -void bdinfo_print_num(const char *name, ulong value); +void bdinfo_print_num_l(const char *name, ulong value); +void bdinfo_print_num_ll(const char *name, unsigned long long value); /* Print a clock speed in MHz */ void bdinfo_print_mhz(const char *name, unsigned long hz); -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 7/7] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng ` (5 preceding siblings ...) 2021-01-21 15:00 ` [PATCH 6/7] bdinfo: Rename function names to be clearer Bin Meng @ 2021-01-21 15:00 ` Bin Meng 6 siblings, 0 replies; 16+ messages in thread From: Bin Meng @ 2021-01-21 15:00 UTC (permalink / raw) To: u-boot From: Bin Meng <bin.meng@windriver.com> There are some calls to bdinfo_print_num_l() with parameters that could be a 64-bit value on a 32-bit system. Change those calls to use bdinfo_print_num_ll() instead. Signed-off-by: Bin Meng <bin.meng@windriver.com> --- arch/arm/lib/bdinfo.c | 8 ++++---- cmd/bdinfo.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/lib/bdinfo.c b/arch/arm/lib/bdinfo.c index 4a98cb7ef5..c905783bdc 100644 --- a/arch/arm/lib/bdinfo.c +++ b/arch/arm/lib/bdinfo.c @@ -18,14 +18,14 @@ void arch_print_bdinfo(void) bdinfo_print_num_l("arch_number", bd->bi_arch_number); #ifdef CONFIG_SYS_MEM_RESERVE_SECURE if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) { - bdinfo_print_num_l("Secure ram", - gd->arch.secure_ram & - MEM_RESERVE_SECURE_ADDR_MASK); + bdinfo_print_num_ll("Secure ram", + gd->arch.secure_ram & + MEM_RESERVE_SECURE_ADDR_MASK); } #endif #ifdef CONFIG_RESV_RAM if (gd->arch.resv_ram) - bdinfo_print_num_l("Reserved ram", gd->arch.resv_ram); + bdinfo_print_num_ll("Reserved ram", gd->arch.resv_ram); #endif #if !(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) bdinfo_print_num_l("TLB addr", gd->arch.tlb_addr); diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index 996546faf3..dfd50ae849 100644 --- a/cmd/bdinfo.c +++ b/cmd/bdinfo.c @@ -55,8 +55,8 @@ static void print_bi_dram(const struct bd_info *bd) for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { if (bd->bi_dram[i].size) { bdinfo_print_num_l("DRAM bank", i); - bdinfo_print_num_l("-> start", bd->bi_dram[i].start); - bdinfo_print_num_l("-> size", bd->bi_dram[i].size); + bdinfo_print_num_ll("-> start", bd->bi_dram[i].start); + bdinfo_print_num_ll("-> size", bd->bi_dram[i].size); } } } -- 2.25.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-01-31 8:35 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-21 15:00 [PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB Bin Meng 2021-01-21 15:00 ` [PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit Bin Meng 2021-01-21 15:00 ` [PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t Bin Meng 2021-01-24 2:03 ` Simon Glass 2021-01-29 17:47 ` Simon Glass 2021-01-30 10:13 ` Bin Meng 2021-01-30 16:24 ` Simon Glass 2021-01-31 3:40 ` Bin Meng 2021-01-31 3:44 ` Simon Glass 2021-01-31 8:35 ` Bin Meng 2021-01-21 15:00 ` [PATCH 3/7] serial: sifive: Cast dev_read_addr() with uintptr_t Bin Meng 2021-01-21 15:00 ` [PATCH 4/7] fdtdec: Cast prior_stage_fdt_address " Bin Meng 2021-01-24 2:03 ` Simon Glass 2021-01-21 15:00 ` [PATCH 5/7] riscv: Change phys_addr_t and phys_size_t to 64-bit Bin Meng 2021-01-21 15:00 ` [PATCH 6/7] bdinfo: Rename function names to be clearer Bin Meng 2021-01-21 15:00 ` [PATCH 7/7] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit Bin Meng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.