Files
u-boot-tk1-som/include
Stephen Warren 48cfca240d 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>
2015-05-13 09:24:12 -07:00
..
2014-07-30 08:48:03 -04:00
2015-04-18 16:54:29 -04:00
2015-05-05 20:58:20 -06:00
2015-01-14 11:35:43 -05:00
2014-02-04 16:32:20 +01:00
2014-02-21 08:42:47 -05:00
2015-04-29 21:02:33 -06:00
2014-06-21 10:06:58 -06:00
2015-04-10 14:23:23 +02:00
2014-10-25 15:27:36 -04:00
2015-04-22 12:14:55 -04:00
2014-12-05 08:06:15 -08:00
2015-01-21 10:25:02 +01:00
2015-04-23 16:46:50 -07:00
2015-03-05 08:56:39 -05:00
2014-11-19 08:48:42 +01:00
2015-01-29 17:09:59 -07:00
2014-12-11 13:18:43 -07:00
2013-09-24 09:10:33 -04:00
2014-10-25 15:27:37 -04:00
2015-05-08 17:24:17 -04:00
2014-05-28 10:58:19 +09:00
2014-06-20 11:54:29 -06:00
2014-10-22 16:56:41 -06:00
2015-04-23 09:05:53 -06:00
2013-09-20 10:30:54 -04:00
2015-05-05 12:29:36 +03:00
2014-05-30 14:03:24 -04:00
2013-11-09 17:21:01 +01:00
2015-01-06 10:10:04 +02:00
2015-04-16 19:27:40 -06:00
2015-01-05 12:08:55 -05:00
2015-04-20 17:57:13 -05:00
2014-11-24 12:00:00 +01:00
2015-03-05 20:50:29 -05:00
2013-12-04 08:11:28 -05:00
2015-01-21 10:25:53 +01:00