On Fri, Dec 25, 2015 at 12:40:25PM +0300, Matwey V. Kornilov wrote:
2015-12-25 12:25 GMT+03:00 Andreas Färber afaerber@suse.de:
Am 25.12.2015 um 10:02 schrieb Alexander Graf: [snip]
The reason I implemented "bootefi" was really because it's the natural fit into how U-Boot handles all other formats today. I don't think this is going to be the last patch set around EFI support.
I think what Matwey was suggesting is integrating your "bootefi" into the standard "distro" boot sequence environment, so that it probes each device for an EFI binary and if it finds one runs load and bootefi, without the need for any boot.scr.
I have no problem if boot{arm,a64,x64}.efi search is implemented via standard bootscript. But I like idea about extlinux.conf too.
That would be a follow-up patch.
It however conflicts with your idea of having some potentially board-specific code mess with "fdt addr" command before running "bootefi".
My solution would be to give boot.scr preference over *.efi, so that the user has a way to load dtb and run "bootefi" on his own, and otherwise fall back to just "bootefi" which'll spit a warning about lack of fdt if I read that correctly.
Yeah, dtb should be anyhow controlled by the user to make workarounds possible. Funny story about how u-boot detects dtb: http://lists.denx.de/pipermail/u-boot/2015-December/237604.html
Yeah. And frankly that's about how it's supposed to work too. That's a very "funny" Beaglbone Black clone you found there (they neither verbatim copied the EEPROM contents nor followed the guidelines on how to get their own name in there). :)
But, in the end it's all a solvable set of problems, after the initial work is in.