Skip to content

EBBR Notes 2024.05.06

Jump to bottom Edit New page
Vincent Stehlé edited this page May 7, 2024 · 2 revisions

Attendees

  • Ahmad Fatoum (Pengutronix)
  • Vincent Stehlé (Arm)
  • Jonathan Humphreys (TI)
  • François Ozog (Shokubai tech)

Agenda

  • Decide if v2.2.0-pre1 is ok for release.
  • OS provided DT proposal (Jon)
    • Context:
      • Problem of firmware provided Devicetree not optimal for the OS.
      • Proposal: firmware to pass only an identifier or filename instead.
      • Follow-up questions on the ML:
        • Are there any generic operating systems that are willing to ship a collection of DTs and to implement the changes to their bootflow to adopt them automatically (rather than through post-install tuning)? (Daniel)
        • Specific cases where Devicetree evolves and compatibility is broken (Rob)
        • Implementation of selecting one DTB in systemd EFI loader implementation is ongoing (multiple DTBs in UKI).

Notes

  • Delay decision to release v2.2.0.
  • OS provided DT proposal presented by Jon.
    • Continue the investigations on DTB sining/measurement and leveraging the load_file2 protocol.

Raw notes

  • Decide if v2.2.0-pre1 is ok for release -> delay
  • OS provided DT proposal (Jon)
    • Problem: often, embedded OS will provide the DTB. But EBBR requires DTB from the firmware. If what is inside the firmware provided DTB does not satisfy the OS we have a problem. Firmware knows the board, but does not know DTB "version" ideal for a specific OS.
    • Idea: separate firmware DTB "family" from version.
    • How does the OS know if it is better to use the firmware provided DTB or the OS provided DTB.
    • The OS loader (from the OS distribution) can peek at the root node compatible string to find on which board it is running, then grab a better DTB if needed.
    • Some remaining issues with DTB fixups done by the firmware, would have to be "transposed" to the OS loaded DTB.
    • Ahmad: in the case of A/B, use OS provided DTB. Would need an OS loader to select the DTB.
    • Jon: GRUB is a common OS loader. If we implement it there, we'll have covered a lot of users.
    • Ahmad did not need an OS loader so far. Could firmware select a Devicetree without an OS loader? Use a simple algo. to determine which DTB.
    • Previous discussions:
    • Security of the DTB; signing, measurements.
    • François: issues with VM, device assignment and Devicetree.
      • Decouple Devicetree from OS. Example of interrupts with disk controller: Linux supports only one interrupt, QNX supports many. Linux should handle this situation gracefully (do not adjust the Devicetree; adjust the OS behaviour).
      • Other example with GPU and VGA overlay buffer; U-Boot can use overlay buffer, Linux will use the full GPU.
      • Long term future: firmware provides DTB not tied to an OS.
      • Does the proposal support that?
    • Devicetree == hardware abstraction, de-facto tied to an OS today. Long term goal: decouple. Is that realistic?
      • Preventing compatibility break with schemas not the definitive solution?
      • Devicetree effectively grows with OS hardware support.
    • François: we do not need a full hw abstraction.
    • Ahmad: comparison with ACPI not fair as Device Tree is data and doesn't contain code.
      • Case of A/B update; UEFI firmware update with new Devicetree would not boot old kernel. Cannot evolve Devicetree without breaking old kernels. Example of i.MX8 and power management, adding power domains. Old Linux does not have drivers to control these newly described power domains.
      • SCMI could solve this?
    • François: critical change to happen is the developers mindset as they expect e.g. Linux drivers to have full control of hardware, even when running under a hypervisor.
      • Ahmad: Firmware is supposed to provide proper device tree, e.g. with SCMI description in this case
    • François: existing option in Linux EFI stub to load an initrd (LoadFile2).
      • re-use load_file2 protocol, used to load initramfs, but to load the DTB.
      • Pass specific argument as device path.
      • Action: ask Ilias about the details.
      • U-Boot can verify signatures for initramfs but this is implementation specific.
    • Ahmad: OS vendor would sign OS-provided DTB.
    • Action: ask Ard about Linux EFI stub advices.

Links

Add a custom footer
Add a custom sidebar
Clone this wiki locally