From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 8 Oct 2015 08:29:10 -0600 Subject: [U-Boot] Inconsistencies in commands regarding load_addr In-Reply-To: <20151008044015.BC4DB380905@gemini.denx.de> References: <5613E20F.8060306@wsystem.com> <20151008044015.BC4DB380905@gemini.denx.de> Message-ID: <56167DB6.3000508@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/07/2015 10:40 PM, Wolfgang Denk wrote: > Dear Beno?t, > > In message <5613E20F.8060306@wsystem.com> you wrote: >> >> I've just noticed that before the commit >> 045fa1e1142552799ad3203e9e0bc22a11e866ea, ext2load and ext4load were setting the >> load_addr global variable, but not fatload. Since then, none of these commands >> set load_addr (initially derived from the loadaddr environment variable). > > That's bad. > >> ubifsload also does not set load_addr, but a quick grep shows that some other >> filesystem commands set it, e.g. for zfs, jffs2, reiser or cramfs. >> >> Also, some commands set it only on success, while some other commands set it >> from the command line arguments unconditionally. >> >> What's the expected correct behavior here? > > After successful loading the data to memory, load_addr should be set > correctly, for all commands. In the error case, the value of > load_addr is undefined. Is this documented anywhere? If not, I'm not convinced that there's a contract to be followed; it "just happens" that some filesystem-related commands work(ed) that way (and as Beno?t pointed out, apparently some don't irrespective of the mentioned patch).