Re: [Arm.ebbr-discuss] Notes from 12 April 2018 EBBR meeting

Hi Grant,

I was on that meeting too. Michal Simek (Xilinx).

Thanks, Michal

On 13.4.2018 21:48, Grant Likely wrote:

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!

---

Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com