From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Beno=c3=aet_Th=c3=a9baudeau?= Date: Fri, 9 Oct 2015 16:01:29 +0200 Subject: [U-Boot] Inconsistencies in commands regarding load_addr In-Reply-To: <20151009131826.51616382C64@gemini.denx.de> References: <5613E20F.8060306@wsystem.com> <20151008044015.BC4DB380905@gemini.denx.de> <56167DB6.3000508@wwwdotorg.org> <20151008212902.065EE382CD2@gemini.denx.de> <56177AC8.1020707@wsystem.com> <20151009131826.51616382C64@gemini.denx.de> Message-ID: <5617C8B9.30204@wsystem.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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