Okay, good. Hello. My name is Patrick Woolowiv and I'm working at my
elements and last year I got the chance to work on U-Boot and actually getting
paid for it. So let's get started. So I got a task. The task was to enable the
SPSA on Raspberry Pi 4 within U-Boot and yeah that's what my daughter is about
about the journey that was necessary to get this done. So the ARM SPSA is a
specification released by ARM. It's intended for server platforms for 64 bit
server platforms and the specification points to the BBR that's the base boot
requirements specification for such servers. And I use this specification to
implement the changes in U-Boot to get it working. Okay, so let's have a look at
the specification. It mandates several items. Some of those were already implemented.
So UFI support and the PSCI support were already done in U-Boot so I don't
had to work on this. It also mandates ACPI support and yeah that's what I implemented.
It also mandates SMBIOS. That's something I did not look at. It's currently not implemented.
Ever it's not required to boot an operating system. It works without SMBIOS.
Yeah, first of all let's have a look at the device three. It's usually used on
embedded platforms like the Raspberry Pi 4 and it's typically not used on server platforms.
While the specification, the SPSA is especially for server platforms.
The device describes what your hat looks like and it allows an operating system or a boot
loader to identify components. One-year computer to load drivers and yeah it allows to reuse
drivers across various computers. So you don't have to know what computer you run on you just
need a device. It tells you everything you need to know. And on the other hand there's ACPI
and it was a replacement for the BIOS. Back in the days you had no chance to know
what hardware you running on or you could do it's called into the BIOS. It was 16-bit code.
It was very slow, very buggy, Windows Pacific and just the pain to deal with. That's why ACPI
was invented. Again, it just describes the hardware. There's the binary representation.
So you compile your ACPI source code into a binary code but it's lossless so you can convert it back
if you want basically disassemble it. On ACPI you have two different kinds of code. You have
tables and you have AML byte code and the AML byte code requires an interpreter in
the US or the boot loader. So that's kind of different compared to the device tree. The device tree
is just a data structure. You don't need an interpreter. Of course you need to understand the data
but ACPI is more complex but on the other hand allows you to give you more control over your computer.
ACPI tables need to be loaded into the DRAM. Usually that's a standby firmware or the boot loader.
Just a short explanation about ACPI so there are multiple tables in your DRAM.
For example the RSTP it just points to another table inside the table multiple pointers to
again different ACPI tables because you can have multiple inner system. Some of those are
like the FADT, the DSTT which contains the byte code I talked about.
But we're look kind of different. So we have a specific name that can be chosen by the
firmware vendor or the manufacturer. We have an identifier that identifies the hardware. In this
case it's an PLO11uart. We have a property that describes where to find this. A specific hardware
here it's a memory mapped at address and has a fixed length and in the end there's also
a status or field that says it's actually enabled and working in your computer.
What can we do to patch the device free? Usually device free is loaded from the spy flash
or provided by early stage boot loader and then you have to modify it to add user specific settings,
port specific settings, change the boot order or the command line. You can do it in line or
unflatten the whole binary device free. Do modifications and then pick it again that means converted
into a binary representation and an example that is given here is used in a huboot.
On the other hand we have the ACPI byte code. Again this can be in line patched.
However currently there's no firmware that allows to parse it, modify it and generate a
amount of byte code of it. What's supported is just generating it at runtime that's usually done in
C. Here's an example how the inline patching is done.
Okay so we look at the computer, the two shows, the other firmware solutions that exist
like QMO, UFI or cobbled that are able to generate ACPI on ARM64.
So the simplest solution is use kernel. It generates ACPI code for your run your virtual machine.
It's just copied into the virtual machine and it allows to you to run your kernel directly.
So that's not an example for us because there's basically no firmware and waft it just works.
Then there are firmware-based solutions so you can run fobbled, EDK2 or Uboot in your virtual machine.
But again it just uses an MMI origin to copy the ACPI tables into the DRAM of the virtual machine.
So even though it's using a firmware, it's not a good example. But it has murking ACPI support on ARM64.
Yeah so UFI. UFI usually has all their ACPI tables in flash. It just loads them from flash places it in DRAM.
And then it's modified in DRAM or in place.
UFI does not use a device tree just hard codes defines them the DCFi.
Similar our cobbled is able to load the STT from flash, place the table in DRAM and all other tables
generated at run time using C code. It does not use a device tree. It has something similar
called device tree.cb but that actually converted into a C file when you build cobbled.
It's possible to generate a STT code as seen here in the example so you call tons of C functions
that generate a MMI byte code. At this point I want to thank Simon Glass.
He started the ACPI enablement on Raspberry Pi 4 back in 2021 and he did a lot of reviewing
and the whole process of upstreaming. And also I want to thank my colleague Max. He picked up Simon's
work, polished the code, moved everything into come folders and then we just call the come code.
I took that over last year July, polished it for upstreaming, sent it upstream and it was denied.
So let's look why. So there were several dues and owns by the maintainers and here at DRAM.
So they said we need an emulated mainboard first so the Raspberry Pi is not an emulated mainboard.
It's not a good example. Start with something else. Because we need to make sure it works
for everybody we can use the CI to run the new code and it allows everybody to confirm the change of
stuff. And they also said device refers to. So not using C code but everything need to be defined
in the device tree. So the issue is this is an ACPI only platform. I will show that in next slide.
And they also said you would drive us should take care of the ACPI code generation by just reading
the device tree. So don'ts are no static, the STTAML code and no static, basically I tables and
C code that are just placed in DRAM. So I added support for the kernel SPSA ref platform that's designed
around the specification by ARM. It provides a minimum of the device tree and nothing else.
It doesn't provide ACPI tables, it doesn't have sort of a config interface. It just gives you a
very, very small device tree and that's it. So what I had to do is add a property-wise T because
that was mandated by your boot developers. And what we do is currently on that platform we merge
the device tree. So there's one that's included into the U-bit binary. There's one that's given by
QMO. Both emerged and then we got a complete device tree for that specific virtual machine.
So the U-bit drivers then match against the compatible string. See here in this example.
And every U-bit driver has something in-board specific or sox-specific C code that generates
those tables. But the ultimate goal is to have just U-bit drivers to generate every ACPI table
in your system by just reading device tree notes. So the Upspinning status,
it was quite a lot of work, much more than expected. I added two boards, the QMO SPSA ref board,
a virtual machine. And the Raspberry Pi 4, with ACPI enabled.
Upspinning completed in 2024. You can check out the release tag that has all the patches included.
So let's review the original task. So I had a basic ACPI support. It works on the Raspberry Pi 4
virtual machine boots on real hardware, but it's not SPSA compliant. Just because the hardware
itself is an embedded platform. It doesn't fulfill this specification. This sox support is also
let's say experimental. It doesn't implement org works. Not all Linux drivers will load or work
correctly, just because it's a very special platform and if lots of special road-con drivers
that needs to be adapted to work with the ACPI. There's an official EDK2 firmware that you can use
on Raspberry Pi 4 that has proper ACPI support. And here's some future plans. So the
adheres to the grid of all the STTAML code, the grid of all the table generation and mainboard code
and subcode and just have your boot drivers to write out tables by powerling the device through.
Also to enable more boards, because currently it's just the Raspberry Pi 4 and the
emulated platform. That's it for my side. Do you have any questions?
Yeah. In two questions, does Hubode still pass the device to binary to the kernel
and how do you deal with overlays in the case of ACPI? So the first question is does Hubode pass the
device through to the kernel? No. So the ideas that only ACPI tables are passed to the kernel,
no device free is provided. And the second question was,
So the device free overlays, I'm not sure if the device free overlays are used within Hubode,
on Raspberry Pi 4. Because currently Hubode is not the first firmware that runs,
there are several other firmware or boot loaders that start before Hubode actually runs. And in the end,
Hubode just gets a complete device free, something that's assembled already and ready for proper use.
That's it, answer your question? Okay, let's go. Next question.
How did you know that Hubode has denied the device that they are not in the board? Because then they
can push all the clock so power the main skeleton to the ACPI, to the ML, etc. Then forget about that.
Isn't possible if you are approached to do that? Isn't possible if you are approached to do that?
Yeah.
Yes, it's possible. So you have to write drivers for everything to generate proper ACPI code for
power domains for clock domains, but it shouldn't be, it should be status and power states for
the device. That's the point. Yeah, I guess you can read this. Yeah, sorry, nice.