diff options
author | Stephen Warren <swarren@nvidia.com> | 2015-04-02 00:40:53 +0300 |
---|---|---|
committer | Tom Warren <twarren@nvidia.com> | 2015-05-13 19:24:12 +0300 |
commit | 48cfca240db06b2945f23b44e37b9a6018cd40fa (patch) | |
tree | abee079e6466595618793ecf90961dd62255d5a8 /include/configs/tegra124-common.h | |
parent | dedc44b466ba24bd4f38840a79067d806d37d709 (diff) | |
download | u-boot-48cfca240db06b2945f23b44e37b9a6018cd40fa.tar.xz |
ARM: tegra: CONFIG_{SYS_, }LOAD{_, }ADDR rationalization
As best I can tell, CONFIG_SYS_LOAD_ADDR and CONFIG_LOADADDR/$loadaddr
serve essentially the same purpose. Roughly, if a command takes a load
address, then CONFIG_SYS_LOAD_ADDR or $loadaddr (or both) are the default
if the command-line does not specify the address. Different U-Boot
commands are inconsistent re: which of the two default values they use.
As such, set the two to the same value, and move the logic that does this
into tegra-common-post.h so it's not duplicated. A number of other non-
Tegra boards do this too.
The values chosen for these macros are no longer consistent with anything
in MEM_LAYOUT_ENV_SETTINGS. Regain consistency by setting $kernel_addr_r
to CONFIG_LOADADDR. Older scripts tend to use $loadaddr for the default
kernel load address, whereas newer scripts and features tend to use
$kernel_addr_r, along with other variables for other purposes such as
DTBs and initrds. Hence, it's logical they should share the same value.
I had originally thought to make the $kernel_addr_r and CONFIG_LOADADDR
have different values. This would guarantee no interference if a script
used the two variables for different purposes. However, that scenario is
unlikely given the semantic meaning associated with the two variables.
The lowest available value is 0x90200000; see comments for
MEM_LAYOUT_ENV_SETTINGS in tegra30-common-post.h for details. However,
that value would be problematic for a script that loaded a raw zImage to
$loadaddr, since it's more than 128MB beyond the start of SDRAM, which
would interfere with the kernel's CONFIG_AUTO_ZRELADDR. So, let's not do
that.
The only potential fallout I could foresee from this patch is if someone
has a script that loads the kernel to $loadaddr, but some other file
(DTB, initrd) to a hard-coded address that the new value of $loadaddr
interferes with. This seems unlikely. A user should not do that; they
should either hard-code all load addresses, or use U-Boot-supplied
variables for all load addresses. Equally, any fallout due to this change
is trivial to fix; simply modify the load addresses in that script.
Cc: Paul Walmsley <pwalmsley@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Simon Glass
Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'include/configs/tegra124-common.h')
-rw-r--r-- | include/configs/tegra124-common.h | 7 |
1 files changed, 2 insertions, 5 deletions
diff --git a/include/configs/tegra124-common.h b/include/configs/tegra124-common.h index f2b3774da8..1aee5c89f4 100644 --- a/include/configs/tegra124-common.h +++ b/include/configs/tegra124-common.h @@ -18,13 +18,9 @@ */ #define V_NS16550_CLK 408000000 /* 408MHz (pllp_out0) */ -/* Environment information, boards can override if required */ -#define CONFIG_LOADADDR 0x80408000 /* def. location for kernel */ - /* * Miscellaneous configurable options */ -#define CONFIG_SYS_LOAD_ADDR 0x80A00800 /* default */ #define CONFIG_STACKBASE 0x82800000 /* 40MB */ /*----------------------------------------------------------------------- @@ -56,10 +52,11 @@ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows * for the FDT/DTB to be up to 1M, which is hopefully plenty. */ +#define CONFIG_LOADADDR 0x81000000 #define MEM_LAYOUT_ENV_SETTINGS \ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ - "kernel_addr_r=0x81000000\0" \ + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x82000000\0" \ "ramdisk_addr_r=0x82100000\0" |