On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@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
- Firmware loads stock DTB into EfiACPIReclaimMemory
- 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
- Firmware loads stock DTB into EfiACPIReclaimMemory
- 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
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader
- 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.