On 26.12.15 19:55, Leif Lindholm wrote: > On Fri, Dec 25, 2015 at 10:25:22AM +0100, Andreas Färber wrote: >> 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". > > This could however be resolved by moving to a model where the > device-tree was considered a component of the firmware (which is how > we treat it in UEFI). If U-Boot had an awareness (if it does not > already) of an FDT being something it should have and know about, then > this could trivially be passed onto bootefi. > This could means a "default_fdt" environment variable which is loaded > automatically before bootcmd is executed.
That part is already the case in my patches :). The difficult bit is what to do when it doesn't work, because the kernel guys consider a dtb to be a "Linux configuration" framework rather than the "hardware description" framework it's supposed to be. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
