The inofficial PowerPC64 porting page


I was an AIX admin in training once and they mentioned, "maybe you can install OpenBSD on this LPAR", I had to wave it off because OpenBSD/powerpc doesn't do 64 bit unfortunately. But it left a need and a want in me to have that one day. When I quit my job due to health reasons I had a lot of time immediately and I bought a 185 EUR Macppc G5 to start a 64 bit port. The purpose of this webpage is to have a reconstructible diary of my porting efforts. Here is some eye candy on this domain as I'm usually building on a DNS server :-).

# ping -c 2
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=243 time=14.280 ms
64 bytes from icmp_seq=1 ttl=243 time=14.416 ms

--- ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 14.280/14.348/14.416/0.068 ms

2018-07-05 (start)

It all started with this thread around the 5th of July, 2018.


At this point in time I sent a a mail out to the list that I've been working on pmap.c mostly, I made a snapshot of files:

and I indicated that I'm showing my work at:


I have shown on the mailing list how arch's look like in relation to the powerpc port (in /usr/src/sys/arch).

             Architecture Hierarchies in OpenBSD

   socppc         macppc  I want it to be:   aim64        power
      \             /                           \          /
       \           /                             \        /
        \         /                               \      /
          powerpc                                 powerpc64

I hope this makes sense. (I could add a few more powerpc64 archs like ps3, qoriq, amiga64). aim64 takes its name from the AIM alliance.


After a week of wrangling with gcc to make it a cross-compiler, I finally started compiling the kernel yesterday with it (it stopped at pmap.c). Overnight someone mailed me a patch on how to build a clang cross-compiler which I'll have to check out and it'll probably take most of my day. I'm at a stage now where I can go back to working on pmap, trap, locore, machdep and co. Here are the snapshots for powerpc64 and aim64 (need to be extracted from /sys/arch, but do check them with tar -tvzf).

A kind person provided a diff to make a clang cross compiler (like said), here is his vanilla diff (I'll have to change it a little for aim64 I think). That's where I am today.


Artistic time-out to gather strength and focus. This is what I drew on my OpenBSD computer (mac-mini amd64) with a wacom tablet. This was done standing up.

If you open the image in a new tab, it has higher resolution.


What a week! It was so hot that I really only managed to get 1 day worth of work done. I managed to compile past pmap.c but that doesn't mean anything even if I manage to get past trap.c will the kernel boot? Doubt it. Next week will likely be similar to this week as it's someone specials birthday and I have some days planned for visiting them. Hopefully in two weeks I'll get a boost and cooler weather. BTW the picture I drew reminds me of sparc64 for some reason.


It's 14 days later since last update. I haven't done much other than looking at the trap.c code a little longer, the kernel would still compile to this point. I'm having trouble fully understanding the part that needs changing so I'm taking my time with it. We're supposed to get another small heatspell so I'm going to sit this out. Silly of me to start a new project during the heat season. At this pace we may see something next year, and if I get my grant I'll have other priorities as well that I must adhere to. If you got your hopes up of perhaps running something this summer I'll have to disappoint you. BTW I'm spending some time watching Amiga X5000 and QORIQ and PowerPC64 keywords on youtube. I kinda want to get an Amiga X5000 after this.


Finally comfy enough to continue working on this. I had to drop a hobby of mine which for some reason wanted more attention from me. Now I'm almost all powerpc64's. I have a guaranteed 4 weeks (except weekends) to work on this and then we'll take a look where I am and whether I have another project that makes money, otherwise I'll be job searching as my main project in october onwards. I told one person in email Christmas 2018 is a good line in the sand whether anything will come from me or not, otherwise not. The realistic goal for a power9 machine is probably 2020. Once a powerpc64 port exists and is self-compiling is when someone can go ahead and evaluate what direction should be taken. Whether its QoriQ or POWER machines as both are attractive.


I'm stuck and procrastinating around an issue. On the order of a few weeks now. Here is a converted (to 64 bit syntax) locore0.S. However it's not byte aligned and may not work I haven't given it much more thought since I'm really stuck on locore.S (and indirectly trap.c). What should be a decent 64-bit replacement for the following call?

mfsr    %r10,PPC_USER_SR        /* save PPC_USER_SR for copyin/copyout*/
mfsr is "move from segment register" and PPC_USER_SR is 13. It is all stored in register 10. It is a 32-bit PPC only instruction and needs to be translated with an equivalent. I'm really a newbie to asm in general and there is no real translation to this, not in the Programming Environment Manual nor anywhere else I looked. In fact FreeBSD has most of their trap code in asm, and to me it's overkill copying all that to OpenBSD.

I'm really in over my head on this, I was worried it would come to this but before the heatbreak I was still optimistic. Querying the community to help. Let me know in email or my other email address.


4 months notice on this domain. On the 21st of January 2019 this domain will expire. I don't intend on keeping it. It was a test domain for my DNS setup. I'll try to find a new webpage for this page by that time but it won't be


The problem from 2018-09-14 and before may be solved. After I queried the PPC community at OpenBSD, someone provided me a link and it seems the

mfsr    %r10,PPC_USER_SR        /* save PPC_USER_SR for copyin/copyout*/
and I'm just going to take the example from here:
#if defined (PPC_OEA) || defined (PPC_OEA64_BRIDGE)
	mfsr	%r10,USER_SR		/* save USER_SR for copyin/copyout */
	li	%r10,0			/* USER_SR not needed */
By replacing mfsr with an li or if there is a lid I'll use that (will have to check).


I'm having problems with this compile, of ASM, would love to hear community feedback what i'm doing wrong:

/usr/cross/aim64/usr/powerpc64-unknown-openbsd6.3/bin/cc -D_LOCORE -\
msoft-float -ffreestanding -fno-builtin-strlcpy -fno-builtin-strncasecmp  \
-fno-builtin-strncmp -fno-builtin-strncat  -fno-builtin-memchr \
-fno-builtin-strlen  -fno-builtin-vsnprintf -fno-builtin-log  \
-fno-builtin-strlcat -fno-builtin-strncpy  -fno-builtin-memcmp \
-fno-builtin-snprintf  -fno-builtin-bzero -fno-builtin-memcpy  \
-fno-builtin-memset -fno-builtin-memmove  -fno-builtin-longjmp \
-fno-builtin-setjmp  -fno-builtin-log2 -fno-builtin-malloc  \
-no-integrated-as -fno-pie -nostdinc -I/usr/src/sys \
-I/usr/src/sys/arch/aim64/compile/IOTA/obj -I/usr/src/sys/arch -DDDB \
-DMAXUSERS=80 -D_KERNEL -D__aim64__ -MD -MP \
-c /usr/src/sys/arch/aim64/aim64/locore0.S
/usr/src/sys/arch/aim64/aim64/locore0.S: Assembler messages:
/usr/src/sys/arch/aim64/aim64/locore0.S:85: Error: symbol `start' is already defined
/usr/src/sys/arch/aim64/aim64/locore0.S:86: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:86: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:90: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:95: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:95: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:97: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:97: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:107: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:107: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:112: Error: offset not a multiple of 4
/usr/src/sys/arch/aim64/aim64/locore0.S:112: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:115: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:115: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:120: Error: offset not a multiple of 4
/usr/src/sys/arch/aim64/aim64/locore0.S:120: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:123: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:123: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:127: Error: syntax error; found `
/usr/src/sys/arch/aim64/aim64/locore0.S:130: Error: unsupported relocation for DS offset field
/usr/src/sys/arch/aim64/aim64/locore0.S:130: Error: syntax error; found `
clang-6.0: error: assembler command failed with exit code 1 (use -v to see invocation)
*** Error 1 in /usr/src/sys/arch/aim64/compile/IOTA (Makefile:866 'locore0.o')
I'm dumbfounded here. Here is the locore0.S file.

On another note I found a book on Amazon, but it's out of print (doh!). ISBN-13: 978-0131987982 . Oh well I'll keep watching out for this book.

The problem above was solved on the same day, I just had to apply myself a little. ;-), I'll have to revisit locore.S and ofwreal.S now. Here is a good site on powerpc(64) asm IBM Developer page. And here is the diffs between the first and the recent diffed locore0.S file.


I got further from yesterday. Here is the most recent error but it's a linker error instead of gnu assembler or clang. In fact I got all pieces compiled, it's at this link stage where it fails, here is the link error. I think I'm just a step away from having a 64 bit kernel. But this doesn't mean anything yet. I'm going to mail the ppc mailing list now.


ct4# ls -l obj/bsd
-rwxrwx---  1 root  wobj  9112687 Oct 14 19:31 obj/bsd
ct4# file obj/bsd
obj/bsd: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1
The very first cross-compiled powerpc64 openbsd kernel. It's probably very panicy right now and I don't have a way to test it yet, as the 64 bit loader needs to be made still. But being able to compile this, is the best of things!


I've starting working on a bootloader and noticed that even Apple do not use XCOFF64 files, which puts the /sys/arch/aim64/stand stuff in possible limbo. Because I need to provide a 32 bit XCOFF file it may not be easy making it with the cross-compiler. I may have to provide one from the macppc directory which is sorta ill. Anyhow I took a look at Apple's BootX loader and after the XCOFF preamble it clearly shows they use an XCOFF32 format:

00000000  01 df 00 03 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 48 00 00 01 0b 00 00  00 02 80 00 00 00 20 00  |.H............ .|
Notice the 0x01DF at the beginning which is the magic for XCOFF32 as written here.

I made the cross-compiler work with 32 bit powerpc.


Here's an update (as usually on fridays/saturdays). The ofwboot seems to load a 64 bit kernel but not sure about the entry offset at the kernel. This must be ironed out still. Also I intend to make everything ina 6.4 vmm again and make the material available so that people can get to this point themselves and then help. I think there is 2 or 3 people itching to do some help other than giving helpful comments in private mails.


Playing with the kernel and trying to get it bootstrapped...I noticed that some functions aren't in the kernel. I blame the binutils patch I have or something. Right now the kernel is compiled with clang, assembled with binutils's gas, and linked with binutils ld. I'm gonna try to use lld instead but first I'm gonna try to bring it all up to 6.4, which will probably bring in more problems. Morale is low right now. Here is what I think happens.

ct4# objdump -d obj/machdep.o | head

obj/machdep.o:     file format elf64-powerpc

Disassembly of section .text:

0000000000000000 <.initppc>:
       0:       7c 08 02 a6     mflr    r0
       4:       fb e1 ff f8     std     r31,-8(r1)
       8:       f8 01 00 10     std     r0,16(r1)
       c:       f8 21 fe e1     stdu    r1,-288(r1)
.initppc is never linked into the kernel either because it's starting with a dot or because it's at offset 0x0. I don't know. I know too little about the binutils patch to even say it's wrong but the end result is that initppc is not in the kernel. and shows up as ? in an nm. Sigh.


OK I'm ready to share what I have. I'm gonna start with an amd64 vmm image (which runs on OpenBSD vmd), this is the line I have configured the image with:

vm "ct6-aimee" {
                   memory 2G
                   disk "/home/vmm/VMM/ct6.img"                                
                   interface { switch "powerpc" }                              
                   owner vmm
                   cdrom "/home/vmm/OpenBSD/install64.iso"                     
                        # disable
You'll need about 2 GB RAM although in a top 1 GB woudl be enough as well. Everything needed is in the /etc/motd. You log in with root password: BURROW3 I just built this vm and upgraded the cross-build environment. So..kernel cross-compiling works but I have to figure out the issue as written about yesterday. ofwboot compiles too. I haven't tested these yet though but will be using this snapshot from now on. The image is xz compressed and expands to 16 GB (the xz is 826 MB large). Here is the xz at The SHA256 checksum of this file is: 1373504b201277143eb9dab1fa47406e8510b10c40c7b485a22a80004c8771ea. Thanks for trying this image, but please only try if you're serious with helping and have an amd64 computer that can run vmm's (this saves me bandwith). Thank you and best regards.


Just an update that I'm still working on this, but I was sidetracked a few times on other issues. Last tuesday I went through ld (and ld.lld) and determined that linking is not the cause of the missing "T" symbols. Or there is some flag that I'm not aware off, I wen through the entire ld manpage and tried turning on/off flags. This is not my favourite type of work because it's less programming but rather knowing compiler/pre-processor/ assembler/and linker. It's a good to know but it sets me back personally on looking over the code and finding problems there. I noticed a handful of people have downloaded the aimee image. Thanks! Maybe you'll be able to surprise me otherwise work for me will continue next week checking every flag of clang to produce the right symbols. The advice to try to compile on macppc architecture with gcc, I haven't done that yet. Thanks!


I've written up a small article on my personal blog outlining what I'll be doing in 2019 programming wise. My main project is a DNS server (which took a backseat, since july 2018), and I need to get back to it. So we have 6 weeks until christmas where I'll be doing work for the 64 bit powerpc port but right now it looks to me like a fail. Please let me know via email if you have suggestions how I can put my (failed) work in a nice presentable fashion to someone who wants to continue on it. Or if someone wants to start with a clean slate on how they can look how I did things. I already indicated that this website will be going away when the domain expires, so I'll put it on another domain or on the site. We'll see. Right now I'm disillusioned that I'll even get an executing kernel after cross-compilation. That was sorta my goal. All in all I gotta say I learned a lot and I worked on my own bleeding edge these last few months. The heat-spur we had this summer really was a bummer since it prevented me from doing much work at all, and I didn't feel fit until september or so.


I've been in contact with a few people who are working on the clang/llvm port for macppc. I'm going to try to cross-build on the macppc machine and see if it makes a difference in symbols (somehow I doubt it but I'm willing to be surprised). I'm really stalled at this. There is a month left before I'm quitting this porting effort, it can't go on forever. If I get a booting kernel at least that'd be a milestone. Right now clang has been building for the last 10 hours on the G5, yep it's a granpa machine (90 nm technology on the CPU's).

Last week I TLS protected this site so you can visit with https. Also I got a reminder from my registrar that this domain is expiring in early 2019 and I should pay for it. But I'm letting it expire. I haven't made the work yet but I'll do it shortly before or after christmas that this webpage gets moved.

So far thanks to everyone who has helped and supported me. I'm really somewhat sorry that this looks like a fail but perhaps someone smarter or more dedicated than me can continue the work, or start on a new fresh slate.


I started writing on a documentation outlining my failure which will be finalised in 20 days. At that time I'll try to archive the page with and then go and enjoy Christmas with my family. I'm going into a new year not as a failure but recognizing that there is a lack of knowledge and skills still to successfully port OpenBSD to 64-bit PowerPC. Whoever wants to take the torch from here, is welcome to. I'm not really sad, as we didn't lose anything, I'm more sad that my followup project grant didn't come to fruition which I found out about yesterday. 2019 is another year, we start with a clean slate.


Here is the CVS REPO (tgz) of aim64 and powerpc64 as taken today from my ct2 vmm.

The project has ended, sorry for failing