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