[v3,1/7] arm: juno: Fix Juno address variables

Message ID 20200427181804.15787-2-andre.przywara@arm.com
State Accepted
Commit 7d6dae0dfb4b056850cde6ff91d06bb5cbda8fd3
Headers show
Series
  • Arm Juno board OF_CONTROL upgrade
Related show

Commit Message

Andre Przywara April 27, 2020, 6:17 p.m.
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.

Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.

This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).

That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 include/configs/vexpress_aemv8a.h | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

Comments

Simon Glass April 28, 2020, 5:57 p.m. | #1
On Mon, 27 Apr 2020 at 12:18, Andre Przywara <andre.przywara at arm.com> wrote:
>
> The U-Boot documentation explains that variables ending with "_r" hold
> addresses in DRAM, while those without that ending point to flash/ROM.
> The default variables for the Juno board pointing to the kernel and DTB
> load addresses were not complying with this scheme: they lack the
> extension, but point to DRAM. This is particularly confusing since the
> Juno board features parallel NOR flash, so there *is* a memory mapped
> NOR address holding a DTB, for instance.
>
> Fix the variables to use the proper names, changing initrd_addr to
> ramdisk_addr_r on the way, which seems to be more prevelant and
> documented. On the way adjust the FDT load address to be situated
> *before* the kernel, since users happened to overwrite the DTB by the
> kernel clearing its .BSS section during initialisation.
> Also remove the fdt_high and initrd_high variables (which were set
> to -1), to allow U-Boot moving those images around.
>
> This should avoid many problems in the future, but breaks loading
> Linux kernels < v4.2, since they expect the DTB to be loaded in the same
> 512MB region as the kernel. If you need to load such an old kernel,
> please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
> load the kernel to the beginning of DRAM).
>
> That fixes loading debug kernels, which happened to overwrite the DTB on
> certain setups.
>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  include/configs/vexpress_aemv8a.h | 28 +++++++++++++---------------
>  1 file changed, 13 insertions(+), 15 deletions(-)

Reviewed-by: Simon Glass <sjg at chromium.org>
Tom Rini May 7, 2020, 1:03 p.m. | #2
On Mon, Apr 27, 2020 at 07:17:58PM +0100, Andre Przywara wrote:

> The U-Boot documentation explains that variables ending with "_r" hold
> addresses in DRAM, while those without that ending point to flash/ROM.
> The default variables for the Juno board pointing to the kernel and DTB
> load addresses were not complying with this scheme: they lack the
> extension, but point to DRAM. This is particularly confusing since the
> Juno board features parallel NOR flash, so there *is* a memory mapped
> NOR address holding a DTB, for instance.
> 
> Fix the variables to use the proper names, changing initrd_addr to
> ramdisk_addr_r on the way, which seems to be more prevelant and
> documented. On the way adjust the FDT load address to be situated
> *before* the kernel, since users happened to overwrite the DTB by the
> kernel clearing its .BSS section during initialisation.
> Also remove the fdt_high and initrd_high variables (which were set
> to -1), to allow U-Boot moving those images around.
> 
> This should avoid many problems in the future, but breaks loading
> Linux kernels < v4.2, since they expect the DTB to be loaded in the same
> 512MB region as the kernel. If you need to load such an old kernel,
> please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
> load the kernel to the beginning of DRAM).
> 
> That fixes loading debug kernels, which happened to overwrite the DTB on
> certain setups.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> Reviewed-by: Simon Glass <sjg at chromium.org>

Applied to u-boot/master, thanks!

Patch

diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h
index 4f3a792f49..6f81760612 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -138,35 +138,33 @@ 
 #define CONFIG_EXTRA_ENV_SETTINGS	\
 				"kernel_name=norkern\0"	\
 				"kernel_alt_name=Image\0"	\
-				"kernel_addr=0x80080000\0" \
-				"initrd_name=ramdisk.img\0"	\
-				"initrd_addr=0x84000000\0"	\
+				"kernel_addr_r=0x80080000\0" \
+				"ramdisk_name=ramdisk.img\0"	\
+				"ramdisk_addr_r=0x88000000\0"	\
 				"fdtfile=board.dtb\0" \
 				"fdt_alt_name=juno\0" \
-				"fdt_addr=0x83000000\0" \
-				"fdt_high=0xffffffffffffffff\0" \
-				"initrd_high=0xffffffffffffffff\0" \
+				"fdt_addr_r=0x80000000\0" \
 
 /* Copy the kernel and FDT to DRAM memory and boot */
-#define CONFIG_BOOTCOMMAND	"afs load ${kernel_name} ${kernel_addr} ; " \
+#define CONFIG_BOOTCOMMAND	"afs load ${kernel_name} ${kernel_addr_r} ;"\
 				"if test $? -eq 1; then "\
 				"  echo Loading ${kernel_alt_name} instead of "\
 				"${kernel_name}; "\
-				"  afs load ${kernel_alt_name} ${kernel_addr};"\
+				"  afs load ${kernel_alt_name} ${kernel_addr_r};"\
 				"fi ; "\
-				"afs load  ${fdtfile} ${fdt_addr} ; " \
+				"afs load ${fdtfile} ${fdt_addr_r} ;"\
 				"if test $? -eq 1; then "\
 				"  echo Loading ${fdt_alt_name} instead of "\
 				"${fdtfile}; "\
-				"  afs load ${fdt_alt_name} ${fdt_addr}; "\
+				"  afs load ${fdt_alt_name} ${fdt_addr_r}; "\
 				"fi ; "\
-				"fdt addr ${fdt_addr}; fdt resize; " \
-				"if afs load  ${initrd_name} ${initrd_addr} ; "\
+				"fdt addr ${fdt_addr_r}; fdt resize; " \
+				"if afs load  ${ramdisk_name} ${ramdisk_addr_r} ; "\
 				"then "\
-				"  setenv initrd_param ${initrd_addr}; "\
-				"  else setenv initrd_param -; "\
+				"  setenv ramdisk_param ${ramdisk_addr_r}; "\
+				"  else setenv ramdisk_param -; "\
 				"fi ; " \
-				"booti ${kernel_addr} ${initrd_param} ${fdt_addr}"
+				"booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}"
 
 
 #elif CONFIG_TARGET_VEXPRESS64_BASE_FVP