Architecture support: powerpc

[ajdlinux]

I work on powerpc, I'd like to wire up powerpc support, but our arch is a bit complex.

Issues for consideration:

• defconfigs: powerpc doesn't have a main defconfig called "defconfig", but rather a few dozen defconfigs for various platforms. For development on current-generation IBM servers, you probably want ppc64le_guest_defconfig, but it's pretty common to need to test 32-bit, embedded, etc platforms even if those aren't the platforms you care about. At the very least we'll need a variable to allow each arch to specify a different default defconfig name which can be overridden in local.sh, but it would be nice to have some way to allow the user to specify other defconfigs, pick from a list, etc.
• 32- vs 64-bit: While qemu does ship both qemu-system-ppc and qemu-system-ppc64, I think the ppc64 variant is a strict superset of ppc and can run 32-bit kernels. Compiler-wise, GCC has powerpc-linux-gnu-gcc, powerpc64-linux-gnu-gcc, powerpc64le-linux-gnu-gcc: the latter two are capable of compiling for the other bitness and the other endianness, they just have different defaults if not called with -m32/-m64 or -mbig-endian/-mlittle-endian. I'm not sure whether the 32-bit compiler is capable of compiling -m64, and I haven't tested if using a 64-bit toolchain while compiling a 32-bit kernel always passes the right options to get it to work.
• Big-endian vs little-endian: qemu and toolchain-wise, this should be straightforward.
• Platform choice: Different platforms (e.g. powernv vs pseries for 64-bit servers, and then Power Macs, e500, etc) require different qemu machine type flags.
• rootfs: The parameters above all affect generation of rootfses as well. Debian ships support for IBM POWER8 and later servers, in little-endian mode, as ppc64el, while 64-bit big-endian is an unofficial architecture available as ppc64, and 32-bit support is gone completely and would need to use something else instead (probably buildroot rather than anything available through mkosi). Realistically, for 32-bit support I'd probably just add some way to self-manage the rootfs, tell the user to generate it themselves, and disable all the commands that manipulate the rootfs.
• Image names: Different platforms will generate different image names, e.g. zImage.pseries vs zImage.pmac. Though at least for some machine types you can just load vmlinux directly without issue...
• Assembly extension: Several of these exist, I would need to pick one.

To start with, I plan on doing the minimum required for a 64-bit, little endian build, for ppc64le_guest_defconfig (which enables both the pseries and powernv platforms), which should just mean being able to override the defconfig make target name. From there, I'll see how far I get...