Uncategorized

Tianocore for OpenPOWER

Andrei Warkentin has ported UEFI to OpenPOWER! Excerpt from readme:

TianoCore UEFI for OPAL/PowerNV (PPC64/PowerPC64 Little-Endian)

This is “UEFI” on top of OPAL firmware. “UEFI” because the specification doesn’t include PowerPC yet (ever?). At some point this experiment will implement reduced-hardware “ACPI” support, mapping the OPAL-based FDT into “ACPI” structures. “ACPI” because it’s also not specced out for PowerPC. It’s getting prototyped on top of QEMU and Skiboot (OPAL firmware).

Why? It’s thought experiment gone too far. In short, there’s IMO value in presenting a common firmware environment shared with other servers (X64, AARCH64). UEFI+ACPI keep the OEMs and IHVs in their comfort zone, and reduce pointless platform boot and configuration variance across different architectures. It also allows plug-in cards to work (assuming EBC ROMs). Petitboot is a nice idea in theory, but in practice it’s probably more suitable to embedded environments rather than whitebox servers that can compete with Intel boxes. UEFI gets us a bootloader environment and device drivers for I/O and booting via storage and networking. OPAL is the abstraction layer for the machine.
[…]

https://github.com/andreiw/ppc64le-edk2
http://osdevnotes.blogspot.com/
https://www.flamingspork.com/blog/2015/08/28/running-opal-in-qemu-the-powernv-platform/
http://github.com/andreiw/ppc64le_hello

Standard

8 thoughts on “Tianocore for OpenPOWER

  1. Benjamin Herrenschmidt says:

    I’ve pushed my WIP stuff, if you try to build it you probably need to either put FatPkg and possibly remove the aspeed driver from the dsc since I cannot distribute that source and I haven’t had a chance to clean things up to do a qemu-only dsc yet (travelling at the moment).

    https://github.com/ozbenh/edk2

    Like

  2. Pingback: Second port of Tianocore to OpenPOWER | Firmware Security

  3. Patrick Georgi says:

    “UEFI gets us a bootloader environment and device drivers for I/O and booting via storage and networking.”

    Now those statements are terribly ahistorical.

    Power has that for longer than (U)EFI exists. It’s called OpenFirmware, a standard for over 20 years – one that Intel deliberately declined in order to protect its IBVs from having to compete in an existing market they had no control over.

    It also had architecture independent option ROMs from the start, unlike UEFI that eventually had to retrofit them with EBC (incompatibly, of course).

    One implementation (for POWER specifically) can be found at https://github.com/dgibson/SLOF

    Like

  4. ricardo says:

    Not quite Patrick. Intel did consider OpenFirmware as a first choice for a CPU uarch-independent option ROM arch for the Itanium platform and had the guys from Firmworks over to discuss that option, but ultimately opted against it and went the EFI Bytecode + VM way. See http://beowulf.org/pipermail/beowulf/2009-November/026956.html for a further elaboration on that. Also, the EBC ISA is relatively simple compared to FCode in terms of complexity, which helps to keep the EBC VM small.

    Like

    • Benjamin Herrenschmidt says:

      On the other hand, the EBC attempts at dealing with 32 and 64-bit difference at runtime is a complete cesspit which makes it very hard to write a compiler for it and such a compiler would violates various semantics of C. It might be a good idea to push for a “64-bit only” variant of EBC that clears that up, so we can write an llvm backend for it easily.

      Like

      • Ricardo says:

        That shouldn’t be too hard considering the fact that we’re talking Firmware here, something that it’s not going to change bitness when put out in binary form. AFAICT it may even boil down to just a “find all instances of natural_width, replace with uint64_t, recompile and ship” treatment. Of course, if the main objective is binaries for several CPU uarchs that differ in bitness compiled from one source, that’s going to be a royal PITA.

        Like

  5. Benjamin Herrenschmidt says:

    Also while I find the device-tree a much nicer HW representation scheme than ACPI tables and have a strong aversion for EFI’s binary path components and general choice of binary data structrures & UUIDs instead of human-readable ASCII, OFW lacks in a few other areas:

    It only provides “methods” if you keep the OFW firmware at runtime with almost nobody does (hint: it’s really hard).

    ACPI, despite all it’s deficiencies, provides a runtime environment for AML that can operate within the OS (with interrupts enabled etc…) and thus has a lower impact/jitter on the overall OS using it.

    So the picture is a lot murky in the end 😉 Most IBM machines stick to OFW because of legacy & history, while our most recent low end offerrings chose a different path consisting of a flat device-tree and a Linux Kernel as a bootloader.

    Whether, we will fully switch to UEFI or even ACPI is definitely an open question, we don’t have specific intentions in that area at this stage. I have ported UEFI as well, mostly as a way to better understand what it’s all about and make informed decisions but for the time being, we will stick to our existing schemes.

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s