3 ms·

I was wondering how Oxide would be able to follow through on their claims to be open sourcing even the firmware for their AMD systems. This makes it a little m

by bradfa 4y ago

I was wondering how Oxide would be able to follow through on their claims to be open sourcing even the firmware for their AMD systems. This makes it a little more clear.

wmf 4y ago
Oxide phbl https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl doesn't use OpenSIL. I assume it's written from scratch based on documentation and maybe looking at AGESA. Why can't other server/firmware vendors do the same? Because they're just not willing to.
- dfox 4y ago
  On AMD's amd64 platforms there is not much for the firmware to do in terms of the platform bring up as everything that is inside the CPU MCM gets initialized to some sane state (by a PSP-like additional management core, but AFAIK it is distinct hardware from PSP) before the actual CPU cores come out of reset. Most of what BIOS/UEFI firmware do on these platforms is about providing the right PC-like abstractions to the running OS. If you control the OS and do not have to support backward compatibility you can shift lot of that logic into the OS itself and you end up with the firmware being essentially an ELF loader, which is not a bad description of what PHBL actually does. On the Intels side of things the FSP is somewhat complex piece of software that does various low-level poking at the hardware in order to make running sane code possible. There probably is a historical reason for that in that AMD started with K8 Opterons which are ccNUMA with packet switched interconnect from the inception and relegating initial power on configuration of that to the amd64-side firmware is not exactly an practical design (at least without breaking various assumptions inherent in the "PC" platform). Contrast that to Intel who got something like 15 years worth of products that used variations of the same Pentium Pro FSB (which as an shared bus removes some of the complexity involved in the platform initialization).

by bradfa 4y ago

I was wondering how Oxide would be able to follow through on their claims to be open sourcing even the firmware for their AMD systems. This makes it a little more clear.

wmf 4y ago

Oxide phbl https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl doesn't use OpenSIL. I assume it's written from scratch based on documentation and maybe looking at AGESA. Why can't other server/firmware vendors do the same? Because they're just not willing to.

dfox 4y ago
On AMD's amd64 platforms there is not much for the firmware to do in terms of the platform bring up as everything that is inside the CPU MCM gets initialized to some sane state (by a PSP-like additional management core, but AFAIK it is distinct hardware from PSP) before the actual CPU cores come out of reset. Most of what BIOS/UEFI firmware do on these platforms is about providing the right PC-like abstractions to the running OS. If you control the OS and do not have to support backward compatibility you can shift lot of that logic into the OS itself and you end up with the firmware being essentially an ELF loader, which is not a bad description of what PHBL actually does. On the Intels side of things the FSP is somewhat complex piece of software that does various low-level poking at the hardware in order to make running sane code possible. There probably is a historical reason for that in that AMD started with K8 Opterons which are ccNUMA with packet switched interconnect from the inception and relegating initial power on configuration of that to the amd64-side firmware is not exactly an practical design (at least without breaking various assumptions inherent in the "PC" platform). Contrast that to Intel who got something like 15 years worth of products that used variations of the same Pentium Pro FSB (which as an shared bus removes some of the complexity involved in the platform initialization).