Tianocore for OpenPOWER

~ hucktech

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/

Running OPAL in qemu – the powernv platform


http://github.com/andreiw/ppc64le_hello

Published by hucktech

8 thoughts on “Tianocore for OpenPOWER”

  1. Interesting, I’ve ported it too but haven’t releases my work yet 🙂 We should definitely compare notes !

    Like

    Reply

  2. 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

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

  4. “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

    Reply

  5. 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

    Reply

    1. 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

      Reply

      1. 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

  6. 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

    Reply

Leave a comment