AMD Preparing "openSIL" For Open-Source Silicon Initialization With Coreboot

[Developer12]

Did the Power10 'thing' with binaries get sorted?

No, and it never will be. The best bet is to wait for POWER11.

There are mandatory blobs required by both the OMI memory bridge chips and in the main processor itself for PCIe that IBM does not have the legal right to open source. They do not own that code.

[Developer12]

So where does this put the PSP? It still has transparent access to RAM and registers and is a black box - unless coreboot can disable or sandbox it? Doubleful.

The PSP still has full control over the system and has already finished starting it up by the time the x86 cores come out of reset, with RAM and most of the chipset already set up by the PSP.

There will be no "sandboxing." You cannot ever sandbox something that physically is the ONLY THING that is capable of starting up your entire computer.

This library does nothing more but help with the setup of the remaining minor bits of the chipset, something coreboot and OCP and Oxide were already tackling.

[Developer12]

Not yet clear with the limited information publicly available so far...

The info is out there. Look at the work by OCP or Oxide to init modern AMD platforms. TLDR: the PSP does all the work, and by the time the x86 cores even start the ram and most of the chipset is already fully set up by the PSP. They're often already running in 64 bit mode too, or close to it.

[Developer12]

This announcement is a colossal nothing burger. Absolutely nothing of value at this stage.

1) There is no indication that this isn't a library that AMD will scrub and throw "over the wall." That was a catastrophe with open source AGESA.

To do this right AMD needs to be actually contributing to the coreboot codebase, just as they contribute to the linux kernel. In the long run they need to actually commit to using and shipping the coreboot code they contribute to.

2) This changes NOTHING with respect to the blobs situation. These chips PHYSICALLY must be init'd by the PSP. The PSP and it's closed firmware start up the chipset, start up the ram, and get most of the chip up and running long before the x86 cores even start.

The only way this changes is either a total redesign of how AMD CPUs work, or they start letting us run code on the PSP and do the init of the chipset and RAM ourselves with open source code.

This library simply helps with the few tasks which remain afterwards. Oxide and OCP already have code to do all of this, but it's nice that AMD is providing an official reference implementation......long after the important bits have already been painstakingly reverse engineered.

[avph]

On a current AMD platform, when the x86 cores come out of reset, they are already running in 64-bit mode with RAM and basically everything else fully initalized. At this point the only thing left for coreboot to do is some minor chipset configuration and maybe PCIe init.

The x86 cores still come out of reset in 16-bit mode with the IP register at 0xFFF0 ;-)

[Adarion]

Now that is some conference talk to look forward to. I hope it will not disappoint. Of course, they do have to find a way with PSP, Pluton and the likes.
I wonder how far they'll go with their many little firmware blobs. For all the little controllers. And I wonder how far 3rd party stuff is involved, if they have any obligations towards Sony or MS, since this stuff might be used on the gaming consoles for digital restriction management purposes and so on. Or simply stupid Netflix "premium" content which wants some encrypted and secured away from the user stuff from network to the very screen output.

Interesting diplomatic wording by the way: "...feature rich solutions such as UEFI to slim, lightweight, and secure solutions such as coreboot."
At least that UEFI could be called feature rich, as this might be the only positive thing about it.

[DanaG]

Heck, even with the PSP limitations, Coreboot would still be a huge improvement over the OEM BIOS on some boards. For example, the Asrock X570D4U-2L2T: the serial-over-LAN is only half-implemented, and there's no option to disable loading the EFI VBIOS from PCIe devices, which breaks the amdgpu drivers (or at least PCIe passthrough) if the ASPEED is primary. And there's no S3 Suspend support. If I could run Coreboot on the thing, maybe I could take the (expensive) board out of my "crap I'll never use again" bin and actually use it again.

[andyprough]

Blobless? not even close. There will probably never be another blobless AMD system ever built.

All the AMD has done, and has been doing since the start of ZEN, is moved all of the sensitive firmware into the Platform Security Processor. It does the chipset init. It does the ram init. It inits most of the interfaces.

On a current AMD platform, when the x86 cores come out of reset, they are already running in 64-bit mode with RAM and basically everything else fully initalized. At this point the only thing left for coreboot to do is some minor chipset configuration and maybe PCIe init.

Wow, somebody's in a bad mood today. I'm well aware that AMD can be trusted slightly less far than I can pick up their entire corporate body and throw it, and that their back doors probably have back doors (same as Intel basically). I was just trying to troll Michael a little bit, I did not mean for you to be slamming us all with such violent facts like this.

[brad0]

It's good to see Michael get all excited like the rest of us to run a blobless AMD system, with Linux-libre kernel and his favorite Stallman-approved distro, like Trisquel or Guix. That will be a fun day of testing.

I like stuff that works, not a door stop.

[WesternSemiconductor]

It's good to see Michael get all excited like the rest of us to run a blobless AMD system, with Linux-libre kernel and his favorite Stallman-approved distro, like Trisquel or Guix. That will be a fun day of testing.

The word "blobless" is nowhere in the article.

Until we hear them speak that word, this is just another marketing effort, like the "binary blobs count as open source firmware" nonsense spouted by these clowns: https://www.opencompute.org/projects...ystem-firmware