add support for PowerPC

[wkornewald]

We already have an OpenFirmware boot loader and other kernel support code, but it needs more work to actually boot Haiku. There might also be endianness issues in our code.

[mmu_man]

Some other stuff to fix would include unguarded inlined asm, arch-dependant kernel stuff, and probably some network issues with addresses and port numbers. Some graphics card drivers might also need some work to be usable (some cards map big-endian versions of hw registers at different addresses).

Note qemu includes a ppc emulator, so you shouldn't need real hw to test.

[kallisti5]

After some clean up (werror changes hrev29804, isync addition hrev31708, missing symbols and isync cleanup hrev32067) the PPC code finally boots again on my G3... We get into the kernel but experience the crash problem detailed in hrev15756:

"

• The PPC boot loader counts the CPUs now and allocates the kernel stacks

(made OF device iteration a bit more flexible on the way -- the search can be restricted to subtree). Furthermore we really enter the kernel... (Yay! :-) ... and crash in the first dprintf() (in the atomic_set() called by acquire_spinlock()). kprintf() works, though.

"

[kallisti5]

haiku-ppc boot status as of hrev32480 on a G4 QuickSilver.. same result on a G3 as well. Multiple boot methods of root FS attempted (CD and USB drive)

[kallisti5]

powerPC boot status as of hrev34879

[kallisti5]

boot status as of hrev34931. Patch by Andres in #5193 does get us a bit further. Here vm tracing in vm/vm.cpp is on.

[kallisti5]

ppc boot status as of hrev35516 on Apple QuickSilver G4

[kallisti5]

ppc boot status as of hrev36388:

Kernel no longer loads, locks up at kernel entry like it did at hrev32480 (see first screenshot). There seems to have been a regression between hrev35516 and hrev36388.

Verified that the generated PowerPC Haiku kernel does not have and Undefined symbols.

[andreasf]

Last time this happened there was an unimplemented virtual method in the VM code. If you could bisect which revision introduced the regression that may help pinpoint which method it is.

[stevenh]

I've just network-booted hrev35516 on my eMac 1.25ghz (have tested with both 256mb RAM and 512mb) and I see the same output as in the above attachment, but instead of "Welcome to Kernel debugging output!" I either see:

Invalid memory access at: #SRR0 01000000 #SRR1 40003030
OR
Decrementer exception at: #SRR0 01000000 #SRR1 40003030

Should I continue trying other revisions? Or am I stuffed due to using an eMac?

[stevenh]

Ok, it turns out that this error above is when it's trying to dprintf from the kernel _start. If I change these to printf (and then include <stdio.h>) it fails when relocating the elfs... if I include <boot/platform/generic/text_console.h> instead of <stdio.h> then it relocates... but still causes the above error.

kallista, you had the same error in comment 2... I haven't had a chance to try kprintf instead, I will do this tomorrow. Any idea what causes this? I imagine there is no printf defined for the kernel in ppc arch at this point? printf works from the openfirmware code though.

Meanwhile, the error above with #SRR at 0x1000000 is just the stack popping back. I had to comment out this in arch_start_kernel.S to be able to use '.registers' once the kernel had returned to the ofw prompt.

[stevenh]

Further investigation indicates that changeset hrev35977 causes the lockup. Seems the memset fails miserably on the ringbuffer for the syslog.

I've confirmed this by leaving gKernelArgs.keep_debug_output_buffer as false and the boot continues to the usual spot. I now intend on working back up the revisions to see if newer changes have fixed the error (double lock...)

Meanwhile, my errors above were due to attempting printfs before the platform/arch init was done.

Investigations will continue tomorrow as to what exactly might be the cause; but create_ring_buffer_etc() on line 134 of kernel/utils/ring_buffer.cpp seems to be the lock. I am running on 256mb of RAM? Could I have run out?

[bonefish]

Replying to stevenh:

Investigations will continue tomorrow as to what exactly might be the cause; but create_ring_buffer_etc() on line 134 of kernel/utils/ring_buffer.cpp seems to be the lock. I am running on 256mb of RAM? Could I have run out?

No, the OpenFirmware code in the boot loader is just ignorant of the debug syslog feature and doesn't unset kernel_args::keep_debug_output_buffer while not allocating a debug_output either. I added an extra check in hrev36748. That should fix the issue (the feature won't work, of course).

[bonefish]

Oh, BTW, this ticket is not supposed to be a pool for all PPC port related issues or regressions. Maintaining a status overview of the missing features is fine, but for all other stuff please open separate tickets. Otherwise this ticket will really get unusable eventually.

[kallisti5]

Status update (hrev38534):

• Hardware PowerBook G3 bronze Laptop
• boot boot_loader_openfirmware via tftp
  1. Boot Haiku disk image via network loader (see netboot-hrev38534.jpg)
     1. Splash screen comes up and makes it to the network card
  2. Boot Haiku disk image via haiku.image burn to CD (see cdboot-hrev38534.jpg)
     1. Debug screen output enabled, unhandled page fault

Thanks for the hard work Andreas! :)

[kallisti5]

root image on cd, PowerBook G3, hrev38534

[kallisti5]

root image via network boot, PowerBook G3, hrev38534