Hi,

Here are the notes from our last meeting. (For next calls, it would be nice people take some notes in the shared scratch document so that we increase quality of them)

Attendees

Tom Rini Joakim Bech (Linaro) François-Frédéric Ozog (Linaro) Ilias Apalodimas (Linaro) Mark Brown (Arm) Heinrich Schuchardt Priyanka Jain (NXP) Jens Wiklander (Linaro) Arnd Bergmann CVS Atish Patra (Western Digital) Grant Likely (Arm) Etienne Carriere (ST)

==================================== I - RISC-V

Atish from Western Digital has a 4 developer team on. Focus on standardized boot flows: - U-Boot SPL + U-Boot. - coreBoot + EDK2

==================================== II - Technical report github

Atul volunteered

FF: What format to use ? RST? MD? Other?

Heinrich: RST and MD are rendered by github.

==================================== III - Technical report outline and content updates

A proposal to be made so that a minimal UEFI set of requirements is defined with DT support.

Frank: Should not put DT spec in the UEFI forum

FF: this is not the goal, the goal is to get references to DT in UEFI

Need to ensure we have terminology that can be applied to all architectures (for instance Arm+TFA+U-Boot and RISC-V+U-Boot SPL+U-Boot).

Please make proposals for content including new sections for the use cases.

==================================== IV- Overlays presentation

Franks Presentation notes:

https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts

https://elinux.org/images/0/03/Elce_2018_dt_bof.pdf

https://elinux.org/Device_Tree_Reference -> OverLays

Overlay made simple with DTC extensions: use a reference to define the place in the tree where the update is to be made:

&{/path/to/node} { <overlay definition> }

Use cases:

Hot swap

Expansion slots (beaglebone)

FPGAs (load from kernel to FPGA; led by Altera/Xilinx)

Not too dynamic, in particular because there are still memory leaks

Use of “apply overlay by the bootload” helps reducing the number of DTS/DTB files to deal with.

plugable CPU: overlay is a solution

few terms to define/standardise/clarify by frank:

Cold-swap = ? < describe the actual use-case in simple terms >

Hot-swap = ? < describe the actual use-case in simple terms >

Real hot-swap will be difficult to support.

Another use case for “hot-swap” is a developer helper to change parameter “dynamically” to avoid a full reboot.

FF: DT event may be a wrong way to deal with dynamism: using bus events to trigger changes seem more natural

Grant: event code is fragile, prefer pre-boot control