[U-Boot] Inconsistencies in commands regarding load_addr

[Benoît Thébaudeau]

On Tue, Oct 6, 2015 at 8:09 PM, Stephen Warren <swarren at 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