Random mumblings of ARM developer
I have several personal projects which generate HTML table with some interesting data in it:
Whenever I had to update them I did that by hand. Which had to end one day…
SystemReady specification mentions that system to be certified needs to be able to boot several operating systems:
In addition, OS installation and boot logs are required:
- Windows PE boot log, from a GPT partitioned disk, is required.
- VMware ESXi-Arm installation and boot logs are recommended.
- Installation and boot logs from two of the Linux distros or BSDs are required.
All logs must be submitted using the ES/SR template.
In choosing the Linux distros or BSDs, maximize the coverage by diversifying the heritage. For example, the following shows the grouping of the heritage:
- RHEL/Fedora/CentOS/AlmaLinux/Rocky Linux/Oracle Linux/Anolis OS
- SLES/openSUSE
- Ubuntu/Debian
- CBL-Mariner
- NetBSD/OpenBSD/FreeBSD
So during last week I went through *BSD ones.
There were several changes done since my previous post on the topic. So after some discussions I decided to write a post about it.
There are improvements, fixes and even issues with BSA specification.
It is over four years since I moved this website from being powered by WordPress to being static set of HTML files generated by Pelican. One of side effects was lack of search option. But not any more.
Modern webdevelopment is completely other area than one I left 16 years ago. JavaScript is no longer language to animate menu or manage change of graphics when user taps on page. And there is WebAssembly when something more efficient is needed.
QEMU has emulation of several machines. One of them is “sbsa-ref” which stands for SBSA Reference Platform. The Arm server in simpler words.
In past I worked on it when my help was needed. We have CI jobs which run some tests (SBSA ACS, BSA ACS) and do some checks to see how we are with SBSA compliance.
One day there was discussion that we need a way to recognize variants of “sbsa-ref” in some sane way. The idea was to get rid of most of hardcoded values and provide a way to have data going from QEMU up to firmware.
As you may know one of my side projects is AArch64 SoC features table. It reports which features of AArch64 processor were recognized by Linux kernel and presented in /proc/cpuinfo file.
But there are moments when I do not want to boot Linux just to check what features cpu cores are capable of. So I wrote an EFI application for it and called it “ArmCpuInfo”.
Some time ago was a day when I reached “ten” years at Linaro. Why “”? Because it was 3 + 7 rather than 10 years straight. First three years as Canonical contractor now seven years at Red Hat employee assigned as Member Engineer.
In 2010 I signed contract with Canonical as “Foundation OS Engineer”. Once there I signed another paper which moved me to NewCo project (also called NewCore but NewCo name is on paper I signed).
On 30th April 2010 I got “Welcome to Linaro” e-mail.
Three years ago I wrote blog post about naming company laptops. Last week I got new one. So new name was needed.
Many things changed during last years. Qualcomm released Snapdragon SoC line for laptops. All were running Microsoft Windows (for Arm) with bastard version of ACPI tables. Took some time for Linux community to get Linux running on those systems. In Device Tree mode as ACPI tables were so bad that it was easier to ignore them.
Apple released laptops and mini desktops with M1 SoC (in many variants) and then M2 (also with variants). With MacOS on them. Again, Linux community started working on getting Linux running there. Device Tree again.