Skip to content
  • Stephen Warren's avatar
    ARM: tegra: CONFIG_{SYS_, }LOAD{_, }ADDR rationalization · 48cfca24
    Stephen Warren authored
    
    
    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: default avatarStephen Warren <swarren@nvidia.com>
    Reviewed-by: default avatarPaul Walmsley <pwalmsley@nvidia.com>
    Reviewed-by: Simon Glass
    Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
    48cfca24