On 08/08/18 01:10, Alexander Graf wrote: > On 07.08.18 09:26, Kristian Amlie wrote: >> 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? > > If you enable distro boot for a board, one of the requirement is that > kernel_addr_r is set to a reasonable value: > > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;h=f8e9752a0fa4244ef0a6f7ee530b0aa218080cac;hb=HEAD#l236
Aha! This link clears up the confusion. >> 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. > > I think this is the best option. Just convert boards you care about > slowly over to distro boot (which implicitly means they also use > kernel_addr_r). For other boards you can not rely on any EFI boot path > enumeration anyway, because the boot command doesn't search for EFI > binaries ;). You're right, I had not thought of that. It makes a lot of sense, we will make this part of our recommendation for board porting then. Thanks! -- Kristian _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
