GeezerVison

TianoCore on PowerPC 64 Little-Endian (OPAL/PowerNV)
====================================================

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

I feel a sense of Deja Vu...
============================
This is not at all related to Benjamin Herrenschmidt's
PowerNV EDK2 tree over at his GitHub.

That tree is the one you should probably be looking at.

https://github.com/ozbenh/edk2

But if are interested in an alternate and completely
unrelated implementation, that is most certainly
never going to go anywhere beyond a proof of concept,
then read on :-).

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.

Status
======

Can boot to UEFI shell. As far as devices only the OPAL console
is available.

See outstanding milestones and issues:
https://github.com/andreiw/ppc64le-edk2/issues

Building
========

You will need a LE 64-bit toolchain to build (i.e. ppc64le-linux).
A good source of toolchains is kernel.org.

After running ./edksetup.sh, modify your Conf/target.txt:
ACTIVE_PLATFORM       = PPC64Pkg/PPC64Pkg.dsc
TOOL_CHAIN_TAG        = GCC49

Then:
$ GCC49_PPC64_PREFIX=ppc64le-linux- build

Running
=======

You will need Skiboot and Benjamin Herrenschmidt's PowerNV QEMU tree.

Good directions for both QEMU/PowerNV and Skiboot:
https://www.flamingspork.com/blog/2015/08/28/running-opal-in-qemu-the-powernv-platform/

After that, assuming skiboot.lid is in current working directory,
$ qemu-system-ppc64 -m 4G -M powernv -nographic -kernel ~/src/edk2/Build/PPC64/DEBUG_GCC49/FV/POWERNV.fd

More invocation notes:
- You may provide a FAT filesystem image via -initrd to be accessible from UEFI.
- You may provide more RAM (-m 6G)
- You may run with -s for gdb stubs. See section at end on debugging.

You should see skiboot messages, followed UEFI booting, eventually booting you
to the shell.

  Shell>
  Shell> devtree
   Ctrl[03] MemoryMapped(0xB,0x40000000,0x4035DFFF)
   Ctrl[18] VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)
     Ctrl[33] Tty Terminal Serial Console
   Ctrl[2F] VenHw(3EBFA8E6-511D-4B5B-A95F-FB38260F1C27)
   Ctrl[30] VenHw(F76E0A70-B5ED-4C38-AC9A-E5F54BF16E34)
   Ctrl[31] VenHw(847BC3FE-B974-446D-9449-5AD5412E993B)
   Ctrl[32] VenHw(9E0C30BC-3F06-4BA6-8288-09179B855DBE)
  Shell>
  Shell> ver -_fv
  UEFI Interactive Shell v2.1
  EDK II
  UEFI v2.50 (EDK II, 0x00010000)
  PPC64LE Prototype ABIv2
  Shell>

Architecture considerations
===========================

TianoCore runs in HV mode and uses the hypervisor decrementer. Future
work may consider autodetecting and being capable of running in priviledged
mode only (such as in a VM).

Code is built as PIE ABIv2 or PIE ABIv1. The early work was done
done with non-PIE ABIv1 (it's not possible to build non-PIE ABIv2).

Platform considerations
=======================

The booting flow on a PowerNV machine would look something like:

-----------  
| hostboot |   This is the low-level initialization.
------------
     |
-----v------
| skiboot  |   This is the OPAL firmware.
------------
     |
-----v------
|   Ipl    |   This is UEFI loader that uses passed FDT and OPAL.
------------
     |
-----v------
|   DXE    |   This is proper UEFI.
------------
     |
-----v------
|   BDS    |   This is proper UEFI: we chose to boot an OS here.
------------
     |
-----v------
|    OS    |   OS can use FDT or ACPI.
------------

The approach taken is encouraged by AArch32 UEFI implementations
and by AArch64 Xen/QEMU virtual UEFI. A lot of EmbeddedPkg
components and design decisions are leveraged.

Debugging
=========

If you run qemu with -s you can debug UEFI with gdb via
my DebugPkg. Last tested with gdb 7.10. You will need python
support. I built my GDB with:

$ ./configure --target=ppc64le-linux  --with-python && make

( needless to say the Python stuff won't work unless you `make install`
  or otherwise ensure that gdb's data-directory matches reality. I build
  my toolchains with a local prefix )

Then you can invoke gdb:

$ ppc64le-linux-gdb ~/src/edk2/Build/PPC64/DEBUG_GCC49/PPC64/GdbSyms.debug
(gdb)
(gdb) target remote localhost:1234
(gdb)
(gdb) source ~/src/edk2/DebugPkg/Scripts/gdb_uefi.py
(gdb)
(gdb) reload-uefi -o ~/src/edk2/Build/PPC64/DEBUG_GCC49/PPC64/GdbSyms.debug
EFI_SYSTEM_TABLE @ 0x208ca018
Connected to EDK II (Rev. 0x10000)
ConfigurationTable @ 0x208ca0d8, 0x6 entries
DebugImageInfoTable @ 0x11fffe018, 0x1d entries
Loading new symbols...
add-symbol-file /home/andreiw/src/edk2/Build/PPC64/DEBUG_GCC49/PPC64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0x208cd000
...
<more stuff happens here>
...
(gdb) (gdb) bt
#0  0x000000011fd38200 in CpuPause ()
#1  0x000000011fd37c7c in TickDelay (Ticks=512000000)
    at /home/andreiw/src/edk2/PPC64Pkg/Library/TBTimerLib/TBTimerLib.c:41
#2  0x000000011fd37d0c in MicroSecondDelay (MicroSeconds=1000000)
    at /home/andreiw/src/edk2/PPC64Pkg/Library/TBTimerLib/TBTimerLib.c:68
...
<more stuff happens here>
...
(gdb)

Note that Ipl symbols won't be present since it's not accounted for
in the EFI_DEBUG_IMAGE_INFO structures. You may want to consider
applying the GDB module scope patch to ease some deubbing.
See https://github.com/andreiw/andreiw-wip/tree/master/gdb

Contact Info
============

Andrei Warkentin ([email protected]).