[U-Boot] [PATCH] ARM: tegra: CONFIG_{SYS_, }LOAD{_, }ADDR rationalization
Paul Walmsley
pwalmsley at nvidia.com
Thu Apr 2 00:49:44 CEST 2015
On 04/01/2015 03:40 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
>
> 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 at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>
Reviewed-by: Paul Walmsley <pwalmsley at nvidia.com>
Thanks Stephen
- Paul
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
More information about the U-Boot
mailing list