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 <afaer...@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.htmlYeah. 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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
