Welcome to my presentation about open source firmware status on AMD platforms on Fosden
2024.
It is a fifth edition already of this presentation.
For those who don't know me, I'm a firmware engineer at Friendep.
We are based in Poland.
We do open source firmware stuff.
I'm mainly interested in core boot, advanced hardware features, security, stuff like that.
I'm a maintainer of a few platforms in core boot.
Sorry, I'm full.
You have to stop.
We don't have the devices.
Two of them.
So we have full.
Two of them.
Yeah.
So yeah, please have a seat and we will continue quickly.
But a few people I think.
Yep.
There's one more here.
One more here.
Yep.
Okay, so yes unfortunately.
There are like two people in the corner.
Yeah.
That's it.
Sorry, excuse.
Okay, come on, come on.
So for those who don't know Friendep yet, we are doing various core boot stuff.
UFI, FWPD, Yocto.
So you may always also find various contributions in those projects as well from us.
And the platforms I will be like mentioning throughout this presentation are mainly on this slide.
This is like kind of glossary.
For the terms I will be using throughout this presentation.
And those processors or micro architectures are either currently now supported in core boot or where supported in core boot up to some point of time.
So if you need to please go back to the slide.
I have uploaded them already onto the system.
So you can always check on that.
And let's start.
So a little recap from the last year.
In the January 2023, we had another release of core boot, which happened to deprecate a few more platforms based on AMD silicon.
We were not fulfilling certain requirements about the code quality and drivers and interfaces that were being also deprecated by this release.
So like we lost a couple of platforms like PCN, GCP-1, Lenovo AMD laptop, the G505S and others.
However, since then there were no more removals of any AMD boards yet.
So that's kind of promising because all that is left right now is like quite modern hardware.
So I don't think it will be like dropped very soon.
Okay, to also recap the recent status about the mobile processors of AMD in core boot.
So last year I have talked about the patches that were sent to the review by Starlabs.
Apparently they had their own design on AMD processors for laptops.
However, since then there were unfortunately no updates and I haven't received any information from Starlabs about any plans or status of it, unfortunately.
For those who track also the other developments like AMD Chromebooks, the AMD, Mendocino and Phoenix are still in development, but the FSP binary, which is responsible for the whole
slickensization for Mendocino has been published, but not yet for the Phoenix.
And of course the publication intervals indicate that it may happen quite soon because we had the interval between season and Mendocino about five months.
So right now it's like passed about...
So it should quite soon happen, but I'm not sure about the release dates.
But yeah, the difference is that the Mendocino is like Zen 2 architecture while Cezanne was Zen 3, so it's also quite...
not so straightforward about the release dates because Zen 3 is like a newer architecture, but then there seems to be some kind of update to an older architecture.
So let's continue with the Corbuth status on a little bit older and newer platforms.
So we also had the initiative to bring back the ASUS KGP D16 platform.
We have been trying to upstream that code that we have rebased to a newer Corbuth revision.
However, we have received a response that it will be like too much work to get it back and probably there is like no manpower to actually review the whole of the code.
So we decided to try to redirect the funds we have received from Immune 5 for the KGP revival to offer some additional features based on the Corbuth Dachar that we released for the KGP.
However, there was no response from them, so this project is kind of stalled.
But yeah, let's leave the bad news behind us and let's move maybe some forward with some more positive news.
There is also an initiative by an individual with a nickname Hanetser.
His name is Marty Plummer and he decided to port MD-FSP to a desktop board.
He is doing it in time as a hobby.
He has had some successes with CISAN-FSP.
However, he has success with Picasso-FSP, so the older micro-architecture than CISAN.
He could sort of boot the platform, but of course there are still some problems to solve.
MD-FSP for example can initialize only soldered down memory, so if you have a platform with typical memory modules, it is kind of problematic.
When he tried to use some kind of newer processor with CISAN-FSP, he faced problems where FSP had CPU IDs hard-coded in there,
so he possibly couldn't get past the insertization for processors that were not intended for use with this FSP.
Also, there is also a problem with the PSP binaries that are actually published for the Chromebooks, so the mobile processors.
These PSP binaries are specially crafted for Chromebooks and the verified boot, and they might not work well also with something that is not Chromebook.
And the hardware that is not Chromebook, because apparently there are some configuration fuses that are distinguishing like a Chromebook device with a non-Chromebook device.
But you have also some new initiatives which are much more promising than hacking with FSP or old platforms, and what I mean to say is servers.
Something that was my many probably considered almost not possible not quite long ago to have open source firmware on servers.
There were moves from Intel to make it happen, and we probably saw some FSPs being released on EDK2, Tynocore.
We have had efforts from 9 elements that were porting some servers on Safari Rapids, for example, but that still uses the old, good-known Intel FSP.
What AMD thought about is like entirely new approach.
Because the model of FSP is like very, very costly, because they have to port the UFI reference code for their silicon into an Intel FSP format,
just like constant work of rewriting, adapting the code, testing, and to be honest, it is not like maintainable and scalable approach.
So what they come up with is the open-sill, which stands for open silicon-icization library, which is fully open-source silicon-icization code for AMD servers.
This project has been announced on OCP Summit in Prague last year, and the initial plan was to show a proof-of-concept on a general platform.
So it is current generation AMD Epic Server processors, and we also have a working Corbuth proof-of-concept, as well as EDK2 reference code as well.
If you want to know more about open-sill, I also encourage you to watch the presentations from the OCP Summit or from the OSFC conference, so they are covering in more detail what open-sill is.
So let's try to summarize how the current state of the open-sill Corbuth looks like.
So I did a quick round and tried to build the general reference board Corbuth binary with these few little simple steps.
And just to show you a few statistics, there are still of course some blobs that are needed, like the PSP, there is no way around that, and they are still quite heavy, like it's like four megabytes, as you can see, the APU, AMD APU firmware.
But comparing to Intel, where, let's say, current generation desktop has one megabyte blob of microcode, four megabyte blob of management engine, and another one and a half megabytes of FSP, that's already like much better situation.
But at the end of the build, we are informed about some missing blobs, which is the APCB.
So the Agiza configuration block, if I recall correctly, it is the input information for PSP, how to train the memory, what is the topology, how to find the training parameters, and stuff like that.
I have later checked that these blobs are somewhere present in OpenSyndery repository, I think.
So I don't know why Corbuth hasn't integrated them, maybe they already did, because this presentation is like two weeks old, so things could happen in the meantime.
So I think it is doable to get those APCB blobs from OpenSyndery for sure.
So we have like a revolutionary approach for AMD for OpenSource firmware on their silicon, but what can we expect in the near future?
According to official AMD information, the OpenSyndery is going into production mode around 2026 with the server processors that will be released that year.
Currently now it is only a proof of concept code, so it is just for evaluation only, and you can use it for personal purposes.
But what is more important, that AMD plans to expand all market segments of their silicon to use OpenSyndery.
So in the coming years we will see all possible platforms that could run OpenSyndery.
So basically we returned to the golden era from like I would say 2000 something, where AMD were releasing also full installation called 4-Dale platforms,
where everybody could actually make a fully OpenSource bios firmware for AMD platforms.
So that is very reassuring and exciting news.
I have also got information from AMD employee about a new library, something like that, which is called the AGSA compatibility layer reduced,
which is a wrapper on the original AMD UFI reference code that can be integrated with Tyanochor EDK2 to boot a Ginoa server platform using UFI firmware.
So it is very Ginoa specific, so building it might be a little bit tricky, even for experienced developers.
It is quite fresh, so don't expect a rocket high quality of it.
It is just an initiative done in probably some free time by one of people who sits together with us today.
Feel free to try it. I haven't yet had time to look at it, but it is there. It is also public repository on GitHub.
Okay, I will speed up a little bit because I am running out of time due to those disruptions in the beginning.
PC engines, probably most of us know what these platforms are, what this company were doing.
They were supporting Corboot for many, many years.
And we see more interest in this platform.
We are going to launch a product based on Corboot with the Shara, where we will offer the standard features that we offered with the standard PC engines firmware,
but we will try to use the UFI, so we will provide more security.
We will have secure boot, we will have setup password, TPM 2.0 support, measured boot, verified boot, stuff like that.
And it also will be available as a subscription, so anybody can donate us to support us and make the development happen for this platform.
Because for the past few months it was quite neglected because PC engines ended the official open source firmware support.
There are also efforts by Felix Held from AMD, which also did some work recently in upstream for this board in free time.
So this platform will still be alive for those who are fans of PC engines.
Change boot. We also have dedicated talk for that, so I will just only briefly mention it.
So we are expanding the possibilities of launching the operating systems with dynamic root of transfer measurement for AMD platforms.
We will cover the UFI boot mode and booting Zen with QPSOS using Anti-AvenMate.
So I encourage you to come to Mach-A's talk, which will be at 20 past 4 p.m. in this room, so you will get more details about this initiative.
And I mentioned Densharo, but possibly not all of you know what this is.
So this is like our downstream Corbo distribution, which aims to make the firmware more approachable for end users and regular people.
So we aim to provide a validated pre-builds of the firmware that are known to work and which are to help spread the open source firmware usage that way.
We also offered the subscription model, which allows the subscribers to integrate directly, for example, with developers, request the features, have the most recent updates earlier than regular public builds.
Also, they are given a special treatment in terms of newsletters and stuff like that.
So a little bonus at the end, which is might also be interesting.
AMD also published the AMD secure encrypted virtualization firmware to GitHub.
This is the firmware that is running on the PSP, so it is very revolutionary publication, I would say.
Because till now nobody released any parts of proprietary co-processors to public.
I haven't heard about Intel releasing any parts of Intel ME code.
So again, AMD number one.
And I would like to give special thanks to Paul Grimes, which is with us here from AMD and Fakesheld for the insights, review and suggestions to the presentation.
And yeah, I'm open for questions if we have time for that. Thank you.
Do we have time for some questions?
Yeah, three minutes, I guess. Please.
Okay, so the question is whether the approach taken by Oxide to bring up a modern platform just using the PSP Blobs could be adapted to Corboud.
Technically, yes. But what Oxide did was still like some bare incision of the IO buses.
They needed to program certain registers to get the PCI Express and stuff like that.
So it's not entirely, let's say, independent from the code that runs on the host.
So they still needed to put some kind of small portion of incision and extract the secret bits needed for the incision.
So what we are right about is that the PSP actually, yeah, it can bring the RAM app and boot the platform.
So you have at least half the responsibility of the BIOS less to do. That's true.
But adapting that thing is, I would say, not so scalable.
And it would result in a very feature-limited result, right?
And other questions? Please.
Do you have a plan to support Corboud with open-sealed on framework laptops?
Our framework laptops?
Yes, there's a plan to support it. It's going to be a proof of concept.
It will not be a full replacement.
For example, it won't support any power management features.
So if somebody wants to build it and put it on their framework device, they can.
The framework is not going to be supporting it. It's going to be independent.
But yes, we will have it for both the 13 and the 16 inch.
Did you ask about AMD?
I've been talking about AMD.
Yes, AMD because open-sealed.
Also, I forgot to mention, I'm sorry, Felix.
This is also like last-minute information.
Felix also pushed some patches for AMD Phoenix to be integrated with open-sealed.
But right now, as open-sealed for the mobile platform, it's not available.
The open-sealed is stopped. But the infrastructure is being prepared, I would say.
So we might probably expect something in not so distant future.
We are out of time.
Yes, I can also answer questions like outside or later. Thank you.