summaryrefslogtreecommitdiff
path: root/include/configs/tegra20-common.h
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2015-04-01 15:40:53 -0600
committerTom Warren <twarren@nvidia.com>2015-05-13 09:24:12 -0700
commit48cfca240db06b2945f23b44e37b9a6018cd40fa (patch)
treeabee079e6466595618793ecf90961dd62255d5a8 /include/configs/tegra20-common.h
parentdedc44b466ba24bd4f38840a79067d806d37d709 (diff)
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/tegra20-common.h')
-rw-r--r--include/configs/tegra20-common.h7
1 files changed, 2 insertions, 5 deletions
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 6330281df7..0841f33bfc 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -24,13 +24,9 @@
*/
#define V_NS16550_CLK 216000000 /* 216MHz (pllp_out0) */
-/* Environment information, boards can override if required */
-#define CONFIG_LOADADDR 0x00408000 /* def. location for kernel */
-
/*
* Miscellaneous configurable options
*/
-#define CONFIG_SYS_LOAD_ADDR 0x00A00800 /* default */
#define CONFIG_STACKBASE 0x02800000 /* 40MB */
/*-----------------------------------------------------------------------
@@ -62,10 +58,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 0x01000000
#define MEM_LAYOUT_ENV_SETTINGS \
"scriptaddr=0x10000000\0" \
"pxefile_addr_r=0x10100000\0" \
- "kernel_addr_r=0x01000000\0" \
+ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
"fdt_addr_r=0x02000000\0" \
"ramdisk_addr_r=0x02100000\0"