From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 6 Oct 2015 12:09:13 -0600 Subject: [U-Boot] Inconsistencies in commands regarding load_addr In-Reply-To: <5613E20F.8060306@wsystem.com> References: <5613E20F.8060306@wsystem.com> Message-ID: <56140E49.4030707@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/06/2015 09:00 AM, Beno?t Th?baudeau wrote: > Hi all, > > 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). Oh dear; I see that has indeed changed. Still, it's been 3 years so I imagine nobody was using the feature? > 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? I'm not quite sure how useful the behaviour is; I'd tend towards not setting $load_addr. If some script wants it set, it can easily do it itself. Did you just notice this while reading code, or does this break some existing use-case? If the latter, it seems reasonable to add the previously-working feature back.