Linaro Connect MAD24

Nowadays we have only one Connect per year. And this year we met in Madrid, Spain.

How did it go for me? Good, better than the previous one.

I attended most of the talks I wanted to see, spoke with countless people, and met most of the people on my “to meet” list.

SystemReady related talks

For me, the main topic at Linaro Connect was SystemReady. There was a track for SystemReady IR on the first day and the next days included additional presentations.

Does SystemReady IR “Just Work”?

Jon Humphreys from Texas Instruments gave an introduction what SystemReady. Explained how systems operated before it, the definition of “Just Works”, and some aspects of testing. He then discussed issues with the current certification process, such as missing firmware files used during testing and problems with errata documents. He also offered recommendations on how to improve the situation.

Looking back on SystemReady IR

Vincent Stehlé from Arm spoke a lot about of history and timelines of involved specifications, the U-Boot features timeline and several statistics about SystemReady certifications along with lessons learned.

30.9% of certified systems were for IR band (only SR was higher with 36%), mostly for older versions of the specification.

We learned that there are three certification labs besides Arm itself. And the plan is to eventually remove Arm from this role.

It was interesting to see which distributions were used during IR certification. Fedora Linux leads with 33.9%, followed by openSUSE at 33% and Debian at 21.1%. Other distributions include Ubuntu, SLES, Rocky Linux and RHEL.

U-Boot for SystemReady IR — Status and struggles

Ilias Apalodimas from Linaro presented the history of U-Boot getting features required for SystemReady IR support. He highlighted some common issues and offered suggestions for improvement.

This talk nicely expanded on the topics mentioned in the previous two talks.

SystemReady as default option for BSPs: Findings from the last SystemReady IoT workshop

Ilias Apalodimas, Pere Garcia Gutiérrez and Peter Robinson presented conclusions from SystemReady’s Advisory Committee workshop.

One idea was that SoC vendors should provide BSP setup in a way that the resulting firmware would already be SystemReady compliant. This would make it easier for OEM/ODM vendors, with some following their own paths while others adhered to the guidelines.

Qualcomm and SystemReady IR, an overview of Qualcomm support in U-Boot and what the future

Caleb Connolly from Linaro shared the story how Qualcomm support in U-Boot improved from terrible to good. He mentioned several quirks and issues encountered along the way.

Arm System Architecture and SystemReady Update

Dong Wei from Arm provided updates on changes to the SystemReady specifications.

I somehow missed that session. It was on my list, but I got distracted by a discussion.

He explained how changes are managed and reminded us how SystemReady bands depend on specifications. Then presented planned changes to BSA, such as creation of VBSA for virtual environments and increase of requirements for future versions.

Another change mentioned was that the SystemReady LS and LBBR recipe of BBR might be deprecated due to lack of interest.

There will be some changes for the SBSA requirements. So far there are no plans to create SBSA level 8, but if a silicon vendor can fulfil all future requirements, Arm may consider publishing SBSA level 8.

The BBSR (Boot Base Security Requirements) specification may become a requirement for future SystemReady versions.

SBSA Reference Platform in QEMU status update

I gave a talk presenting what we achieved in the past year regarding the SBSA Reference Platform in QEMU, Trusted Firmware and EDK2 projects.

I discussed changes to virtual hardware, firmware and the methods we use to transfer configuration data between layers. I explained why I use “Datatree” term instead of “Devicetree” and outlined our plans for the future.

Other sessions

I attended other sessions as well and watched several ones I missed due to discussions or schedule conflicts. Here I want to write about some of them.

TianoCore community update

Leif Lindholm provided an introduction and updates on the TianoCore EDK2 project.

He covered which specifications it implements, how repositories are structured, the licenses used and the communication methods. Also discussed updates to SSL/TLS libraries and toolchain profiles, contribution rules and recent changes to there rules.

Additionally, he outlined plans for changes to edk2-platforms such as creating stable tags and implementing automated CI.

An Arm laptop project conclusion

Johan Hovold shared information about the state of Linux on the Lenovo Thinkpad x13s laptop (which comes with Windows for Arm by default).

The good part is that most of the support is already merged into upstream projects and the required kernel configuration changes have been included in several distributions.

The bad part? There is still a lot of work to be done. I wonder when vendors will learn how to write proper ACPI tables (x13s uses Devicetree to run Linux).

Rethinking the kernel system call entry

Arnd Bergmann from Linaro spoke about his work on rethinking the Linux kernel system call entry.

He covered how system calls are currently defined now in the Linux kernel. Then showed how he changed it to be more readable.

I have my system calls table but had never looked how kernel code for them looks. Turned out that it can be quite intimidating with macros expanded to macros resulting in complex C code.

Arnd showed that it can be made readable. I hope that his work will land in the Linux kernel soon.

End words

Linaro Connect MAD24 was a success. I got ideas for blog posts, met people who read my posts.

And if you want to watch more talks from conference then there is official Linaro Connect MAD24 playlist on YouTube.

Visit Linaro Resources Hub for video recordings and presentation slides.

aarch64 arm conferences linaro travels