On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt <xypron.g...@gmx.de> 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.
g.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
