Here are the notes from yesterday’s meeting. Props to Daniel Thompson for taking notes!

Note: I didn’t capture the full list of attendees. If you were there, but aren’t in the list then let me know so I can add you to the official list. Eventually I’ll post these notes on a wiki for the project.

12 April 2018 Attendees - Grant Likely (Arm) - Ryan Harken (Linaro) - Ruchika Gupta (NXP) - Tom Rini (Konsulko) - Peter Robinson (Red Hat) - Alex Graf (SUSE) - Daniel Thompson (Linaro) - Ben Eckermann (Incomplete list; Did not get full list of dial ins)

Agenda: - Status and action item updates - Other business

Notes: Status - No progress on legal issues to get things shared for outside contributions - No progress on converting EBBR to sphinx document

Devicetree - Committee meeting will shrink scope to cover governanceissues (process, release process, etc). - Will be starting a regular technical sync up call soon

AOB - EBBR and different architectures - Alexander Graf has started talking among u-boot team about extending linuxefi support more widely - Udit K: What to do about architectures that are not yet in UEFI? # Grant: Not really in scope for EBBR, they should work with UEFI forum - Grant: EBBR should be opt in (i.e. architecture representatives join us) rather then encompassing “everything” - Udit K: What about big endian? - Grant: Not UEFI… it merely looks like it. - Tom: EBBR references other specifications, needs other specifications to take big endian before we move on it - Udit K: How to handle devicetree updates? - Grant: DT owned by platform is important, not discussed how to update it - Grant: Should we create a DT specific section in EBBR? - Udit K: Ideally, yes. We understand devicetree is owned by the platform but we have had better results using the devicetree in the kernel - Peter: UEFI capsules? - Alexander: Could use overlays to cope with difference between kernels - Alexander: We cannot assume DTs will always be backwards compatible - Grant: Historically have worked to ensure new kernels work with old devicetrees but not old kernels with new DTs - Need to make sure firmware can always be recovered to a ‘safe’ state, and that DT updates don’t require reflashing the entire firmware.

Action: form sub team to draft DT update requirements.

When can others contribute? - Expect to get things tidied up this week but the mailing list is open please discuss things here!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.