[U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

[Kristian Amlie]

On 07/08/18 00:06, Alexander Graf wrote:
> On 06.08.18 13:00, Kristian Amlie wrote:
>> Ping. Any objections to this change?
> 
> I definitely don't want to have the bootefi path behave any different
> from the other distro boot targets. That would just cause confusion down
> the road.
> 
> Do they (pxe boot, extlinux, etc) make use of loadaddr?

No, you're right, apparently they use kernel_addr_r AFAICS [1].

So maybe it is better to stay with kernel_addr_r. The problem is that
not all boards follow this, and there are various "bootm ${loadaddr}"
and "bootz ${loadaddr}" sprinkled across the various board headers,
indicating that they use this.

What I want out of this exercise is to make sure that the EFI path in
distro_bootcmd will be able to boot an EFI app on any board, regardless
of whether it uses kernel_addr_r or loadaddr. Sounds reasonable, right?

Following that it seems natural to standardize on one of the two, but it
is not entirely clear from the source code which one it should be. I
picked loadaddr because it has a CONFIG_LOADADDR define, unlike
kernel_addr_r which is just hardcoded in a lot of places, and thus
seemed less "proper". But I'm fine with staying with kernel_addr_r as well.

There are several things I could do from here on:


1. Keep the current patch, but add "loadaddr" to pxe and extlinux
variants as well to get consistent behavior.

2. Reverse order of attempts, and try to use kernel_addr_r first, then
loadaddr. Possibly this could also include a patch to pxe and extlinux
to make them behave the same.

3. Do nothing, and keep kernel_addr_r as the one and only. IMHO this
implicitly means that loadaddr should be deprecated and removed, given
their overlapping meaning, and boards converted to using kernel_addr_r.

4. Opposite of 3, make loadaddr into the one and only, and convert all
boards to that.


Personally I think either option 1 or option 2 is the best, both quite
smooth transition paths. Option 3 or 4 are perhaps cleaner solutions in
the long term, but are *a lot* more work, and much more likely to cause
breakage as well.

What do you think?


[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=cmd/pxe.c;h=5609545de575d090b27f48fd0d2d2ee61b8bdc73;hb=HEAD#l701

-- 
Kristian