[PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB

[PATCH 0/7] Allow booting a 32-bit system with a top memory address beyond 4 GiB

[Bin Meng]

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

[PATCH 1/7] riscv: Adjust board_get_usable_ram_top() for 32-bit

[Bin Meng]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Bin Meng]

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

[PATCH 3/7] serial: sifive: Cast dev_read_addr() with uintptr_t

[Bin Meng]

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

[PATCH 4/7] fdtdec: Cast prior_stage_fdt_address with uintptr_t

[Bin Meng]

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

[PATCH 5/7] riscv: Change phys_addr_t and phys_size_t to 64-bit

[Bin Meng]

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

[PATCH 6/7] bdinfo: Rename function names to be clearer

[Bin Meng]

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

[PATCH 7/7] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit

[Bin Meng]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Simon Glass]

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>

[PATCH 4/7] fdtdec: Cast prior_stage_fdt_address with uintptr_t

[Simon Glass]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Simon Glass]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Bin Meng]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Simon Glass]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Bin Meng]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Simon Glass]

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

[PATCH 2/7] global_data.h: Change ram_top type to phys_addr_t

[Bin Meng]

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