On Tue, Oct 6, 2015 at 8:09 PM, Stephen Warren <swar...@wwwdotorg.org> wrote: > 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?
Probably. >> 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. Actually, I was working on an older version of U-Boot based on 2012.07, and I got an issue using bootm without any arguments because ext2load was unexpectedly setting load_addr (this was undocumented). So I checked how things evolved in mainline in the meantime, and I noticed the change. I prefer the new behavior, but still, not all current commands do the same. Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot