From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 25 Dec 2015 12:04:54 -0500 Subject: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command In-Reply-To: References: <1450792676-109541-1-git-send-email-agraf@suse.de> <1450792676-109541-9-git-send-email-agraf@suse.de> <567D0634.4010302@suse.de> <567D0B82.2030108@suse.de> Message-ID: <20151225170454.GE4093@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 : > > 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: