uboot: possible inconsistency with hardcoded values for kernel load addr and dtb load addr vs. variables?

[pdscomp]

Do you know why mainline ubootis hardcoding values for the kernel load and boot (and the device tree load?):

bootcmd=fatload usb 0:1 43000000 zImage; fatload usb 0:1 43800000 elegoo-centauri-carbon1.dtb; bootz 43000000 - 43800000

in theory it should be using ${kernel_addr_r} and ${fdt_addr_r}. However those are defined incorrectly in Mainline uBoot since the DSP reserves that address space:

  dsp42000000    reg 0x42000000 0x00100000   no-map

and

=> printenv kernel_addr_r
kernel_addr_r=0x41000000
=> printenv fdt_addr_r
fdt_addr_r=0x41800000

It doesn't seem to be negatively affecting anything but it might be an easy fix?

It sounds like the ideal steps to boot this way would be essentially:

=> usb start
=> fatload usb 0:1 ${kernel_addr_r} zImage
=> fatload usb 0:1 ${fdt_addr_r} elegoo-centauri-carbon1.dtb
=> bootz ${kernel_addr_r} - ${fdt_addr_r}

If those variables were set to 43000000 and 43800000 respectively.

For reference the bootcmd we are using:

bootcmd=fatload usb 0:1 43000000 zImage; fatload usb 0:1 43800000 elegoo-centauri-carbon1.dtb; bootz 43000000 - 43800000

[jamesturton]

I set the load addresses differently when I was testing chaining boots from the stock u-boot. But that's not needed now if we have SPL working or loading from FEL. We can safely use the default addresses as the DSP uses sharespace @ 0x42000000

For now I'm going to keep the bootargs and bootcmd overriden to boot from USB for testing as I think that's the most convenient, but I'll revert to using default addresses.