Dear Wolfgang, On 09/10/2015 15:18, Wolfgang Denk wrote: > Regarding the "load address" topic, be careful, as there has always > been a lot of confusion (due to unfortunate historic choice of names). > There is the "load address" as part of the image formates (uImage, FIT > image), which means the address where the image (OS code) gets loaded > (or even uncompressed) _to_. This is recorded in the image itself, > and has nothing to do woth the "loadaddr" variable, which states where > the image is located in system memory.
Indeed, but I was only referring to the load address below. > A command, that _loads_ an image to memory, should either use the > current setting of "loadaddr" (if no argument is given), of, if the > argument is given, set "loadaddr" to that value, so that further > commands can refer to that address by default. Makes sense. Currently, it's all mixed up between CONFIG_SYS_LOAD_ADDR, the loadaddr environment variable and the load_addr global C variable. The 1st issue is that loadaddr and load_addr currently diverge if the user changes loadaddr or if commands change load_addr. The 2nd issue is that some commands use the value of loadaddr as a default, whereas others use load_addr. And if that fails, CONFIG_SYS_LOAD_ADDR is sometimes used as a fallback value. The 3rd issue is that some read/load commands set load_addr, but not all (e.g.: mmc read, ext2load), which breaks the whole feature, but fixing this could break existing configurations relying on the current behavior. Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot