On Wed, 6 May 2020 at 15:56, Grant Likely <[email protected]> wrote:
> > > On 05/05/2020 16:57, Ard Biesheuvel wrote: > > On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt <[email protected]> > wrote: > >> > > ... > >> > >> As long as device-trees loaded by an EFI application like GRUB do not > >> fully describe boards and miss on copying memory reservations, > >> boot-hartid and everything else needed for successful booting the > >> requirement not to fix-up device trees is not plausible to me. > >> > > > > This is a fair point. The point I made was about firmware relying on > > changes made by the kernel's EFI stub between entry and the point > > where it calls ExitBootServices(). > > Can we create a flow-diagram of who needs to modify what? Here's a first > attempt: > > Scenario 1: Firmware provides DTB > > 1) Firmware loads stock DTB into EfiACPIReclaimMemory > 2) Firmware updates DTB /chosen and /memory with current config > ---- DTB becomes immutable to firmware > 3) Firmware calls EFI Application or OS Loader > 4) ExitBootServices() > 5) OS Consumes firmware-provided DTB > > Scenario 2: EFI Application provides replacement DTB and handles fixups > > 1) Firmware loads stock DTB into EfiACPIReclaimMemory > 2) Firmware updates DTB /chosen and /memory with current config > ---- DTB becomes immutable to firmware > 3) Firmware calls EFI Application which provides replacement DTB > a) Application loads replacement DTB into EfiACPIReclaimMemory > b) Application updates replacement DTB with /chosen & /memory from > default DTB > c) Application calls OS Loader > 5) ExitBootServices() > 6) OS Consumes replacement DTB > > Scenario 3: EFI Application provides replacement DTB; but depends on > firmware to provide fixups > > 1) Firmware loads stock DTB into EfiACPIReclaimMemory > 2) Firmware calls EFI Application which provides replacement DTB > a) Application loads replacement DTB into EfiACPIReclaimMemory > b) Application calls OS Loader > 3) ExitBootServices() > a) Firmware updates current DTB /chosen and /memory with current config > ---- DTB becomes immutable to firmware > 4) OS Consumes replacement DTB > > These are obviously trivial descriptions, but I'd like to flush out what > is actually required. There is going to be tension here between what OS > vendors need, and what vertically integrated embedded users will need. > > This flow is the target of a set of work items in the DTE project. I wouldn't describe the result of work before we actually complete the work ;-) If the goal is to give an overview of what is currently happening with U-Boot, I would use what Heinrich described earlier in the thread. BTW, > g. > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
