From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Date: Fri, 25 Dec 2015 10:25:22 +0100 Subject: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command In-Reply-To: <567D0634.4010302@suse.de> References: <1450792676-109541-1-git-send-email-agraf@suse.de> <1450792676-109541-9-git-send-email-agraf@suse.de> <567D0634.4010302@suse.de> Message-ID: <567D0B82.2030108@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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. 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. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)