Still a way off. Last few weeks it got closer, but it still fails to boot. It also emulates quite old hardware so though it might be okay, it probably is less useful than qemu. It is really targeted at classic old world hardware.
1 Like
Hi everyone,
I recently tried to build Haiku for PowerPC on a Debian 12 VM, with all the toolchains properly set up (following the wiki instructions and some forum threads).
The result? The process fails miserably before even getting to the actual build stage. Forget booting anything – I couldn’t even generate a working ISO.
That said, at least I gave it a shot.
Are there any updates on the PPC port? Has anyone made any progress in the past few months?
Would be great to know if there’s still some activity going on, or if we’re officially in deep freeze.
Cheers!
I was a bit busy with some other stuff in the last weeks. I’ve implemented a very simple dhcp client that allows netbooting Haiku with a local copy of the bootloader, but that is not upstreamed yet, as I had some university-related stuff to do. I’ll try to have a look at getting the kernel to actually load, however, I at least don’t know how much time I’ll have in the coming months.
kind regards,
zeldakatze
Thanks for the update, and congrats on the DHCP client – even if it’s not upstreamed yet, it’s great to know someone is still working on PPC support.
Totally understand the university commitments. Your efforts are very much appreciated, and we’ll be looking forward to any future progress whenever time allows.
Good luck with your studies!
1 Like
At the moment you probably need to do a “bootstrap” build, which is a bit more complicated and fragile than the normal build.
So, yes, we’re really not at the stage where you can build it just to try if it will run. The time is more for investigating buildsystem issues, updating documentation on the build process, and the like.
hello,
okay, some progress: In the upstream build, the kernel fails to load since the binary is missing a seperate data LOAD header. By manually patching the kernel’s linker script to have seperated text and data LOAD segments like @Yn0ga did, the kernel actually loads. By disabling the boot splash,
you can see that the kernel starts and then goes into kdebug. However, the kernel runs without any modules, since they only have one LOAD header and can thus not be loaded. I’m quite confused as to why this happens and also why this only happens on ppc. I thought that by default ld creates multiple LOAD entries and on every other architecture, this seems to be the case.
Does anyone have an idea, why this happens? I could not find a default ldscript or similar and there don’t seem to be any big differences between ppc and other architectures. It looks like it has something to do with the toolchain itself, so I’ll check that aswell once I find some time.
kind regards,
zeldakatze
2 Likes
I just had a quick glipse at these tickets and they do not seem to really have to do with these kind of linkage problems. Especially since you can see the haiku kernel being loaded in Ticket 1048 (it gets to the kernel debugger) so the linking must have worked properly at some point (unless the way the bootloader reads elfs has changed). I might have a look if there is some kind of regression in the buildtools.
Another victim of marcoapc posting unrelated links in discussions. He does that all the time. I recommend ignoring him and not wasting your time.
Anyway, kernel add-ons are linked using the KernelAddon rule defined in build/jam/KernelRules. There is indeed no ldscript there, that shouldn’t be needed. The main control will be through HAIKU_KERNEL_ADDON_LINKFLAGS which can be tweaked as needed in build/jam/ArchitectureRules. Currently nothing special is set for powerpc, but -z noseparate-code is set for clang (this would create a single load segment, I think).
It looks like this option is not enabled by default in ld unless building for linux x86 (as seen in binutils/ld/configure.tgt line 1179), so it seems to be a good idea to enable it explicitly for all our kernel things. The alternative would be to change the kernel elf loader so it can handle single-load executables.
I think the option may not be needed if the default linker script does not put the data and code right next to each other. In that case, ld will generate two PT_LOAD sections, not because of separating code and data, but because the two things are already at separate addresses anyway. So maybe that makes it work by accident on other architectures, but on ppc it happens that code and data are next to each other and end up in the same section?
2 Likes
What victim?
The purpose of a forum is to present ideas and seek solutions. The solution does not always come from the answer, but rather from the debate of ideas. I believe that no one who is technical in their conception can present ideas. If they are technical, they cannot make mistakes.
Learn to respect others regardless of their successes and mistakes, be humble or keep quiet.
You are wasting people time by sending them in wrong directions, repeatedly and despite many complaints and requests to stop.
Either you do not realize how much time people will spend researching the links you posted. trying to understand them, and finding out that it didn’t help them.
Or, you are doing this intentionally to waste people’s time.
If you want to contribute useful things, you have to spend considerably more time yourself understanding the problems and finding actually related links, explain why they are related, and why you think they can bring a solution. Your pasting of random links put that effort on the person who reads your message. As such, they are victim, since you send them on wrong directions, and waste their time. Please stop doing that, as you have been asked to many times already.
4 Likes
You have been told time again, and again, and again to not post unrelated links. You have already been suspended once for this.
I’m suspending you for 4 months. If you do this again you will be permanently suspended from the forums.
3 Likes
It would make sense to have seperate LOAD headers, as you can set different access permissions (RW on DATA, RE on code). On Debian/ppc, gcc seperates the headers like that by default aswell. I’ll look at the toolchain and try to find out the differences there
The bootloader (and possibly the kernel ELF loader also) only supports ELFs with one TEXT and one DATA section; the TEXT section is expected to be RX and the data RW. By default, Clang + LLD create multiple of each, so we have to specify some -z flags to get back the old behavior for the kernel and addons. (runtime_loader properly supports this so we don’t need to set it for userland binaries.)
Since i recently stumbled upon this in relation to this, can someone explain what the “linkhack.so” is used for? It looks to just be an empty file. Why is this required?
A bit of digging reveals the commit that intrduced this in NewOS back in 2001: https://github.com/travisg/newos/commit/8319f2b02bc9b77720cf2d9922233b4421f8df9f
The commit message explains it briefly, we want the kernel to be exported as a shared library with a dynamic section, so that we can link kernel add-ons against it. Linking against a .so did the job back then. There may be cleaner way to achieve it.
The comment in the makefile was lost when migrating to jam, I guess it could be rescued and reintroduced
2 Likes
The NewOS kernel has been supporting ppc for a long time. What made Haiku has a much slower progress than NewOS in porting to ppc?
Lack of interest from the developers. Apple stopped making PowerPC hardware in 2005, at which point Haiku was in early development. So people have been more interested in newer systems and focused on x86.
There were some effort by Bonefish (on a mac mini) and later by mmu_man (on a Sam440 board), but one developer having a look into it from time to time is not enough to keep things progressing, you can only fix the problems that accumulated since last time you looked into it.
Lately there seem to be a bit more people hacking on it and making decent progress 
5 Likes
I tried to build @minimum-raw for ppc, It has some problems compiling gcc_syslibs 8 or something.
I tried using gcc_syslibs13 instead. But it is not available for ppc. How can i get this available? I have the ppc targeting toolchain already build
Do a bootstrap build. As long as the system is not bootstrapped and the prebuilt packages updated, normal builds won’t work.
hello again,
I’ve had a look at the linking issue on powerpc which seems to be a regression between
btrev43147 ( gcc: Change ARM typeinfo behavior to match other architectures.) and btrev43149 (binutils: Fix powerpc gas target for Haiku) (The regression very likely happend with btrev43148 which imported binutils 2.38).
Running objdump -x on a test executable compiled with btrev43147 yields
objdump for btrev43147
helloworld: file format elf32-powerpc
helloworld
architecture: powerpc:common, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000000
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x000001e4 memsz 0x000001e4 flags r-x
LOAD off 0x000001e4 vaddr 0x000011e4 paddr 0x000011e4 align 2**12
filesz 0x00000068 memsz 0x00000068 flags rwx
DYNAMIC off 0x000001e4 vaddr 0x000011e4 paddr 0x000011e4 align 2**2
filesz 0x00000058 memsz 0x00000058 flags rw-
EH_FRAME off 0x00000198 vaddr 0x00000198 paddr 0x00000198 align 2**2
filesz 0x00000014 memsz 0x00000014 flags r--
Dynamic Section:
HASH 0x000000b4
STRTAB 0x00000154
SYMTAB 0x000000e4
STRSZ 0x0000001f
SYMENT 0x00000010
Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 00000030 000000b4 000000b4 000000b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00000070 000000e4 000000e4 000000e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 0000001f 00000154 00000154 00000154 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .text 00000024 00000174 00000174 00000174 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .eh_frame_hdr 00000014 00000198 00000198 00000198 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .eh_frame 00000038 000001ac 000001ac 000001ac 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .dynamic 00000058 000011e4 000011e4 000001e4 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .got 00000010 0000123c 0000123c 0000023c 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .comment 00000011 00000000 00000000 0000024c 2**0
CONTENTS, READONLY
SYMBOL TABLE:
000000b4 l d .hash 00000000 .hash
000000e4 l d .dynsym 00000000 .dynsym
00000154 l d .dynstr 00000000 .dynstr
00000174 l d .text 00000000 .text
00000198 l d .eh_frame_hdr 00000000 .eh_frame_hdr
000001ac l d .eh_frame 00000000 .eh_frame
000011e4 l d .dynamic 00000000 .dynamic
0000123c l d .got 00000000 .got
00000000 l d .comment 00000000 .comment
00000000 l df *ABS* 00000000 helloworld.c
00000000 l df *ABS* 00000000
000011e4 l O .dynamic 00000000 _DYNAMIC
00000198 l .eh_fram]e_hdr 00000000 __GNU_EH_FRAME_HDR
00001240 l O .got 00000000 _GLOBAL_OFFSET_TABLE_
0000124c g .got 00000000 __end
0000124c g .got 00000000 __bss_start
00000174 g F .text 00000024 main
0000124c g .got 00000000 _edata
0000124c g .got 00000000 _end
Whilst running objdump -x on the binary compiled with btrev43149
objdump for btrev43149
helloworld: file format elf32-powerpc
helloworld
architecture: powerpc:common, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000000
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
filesz 0x000011a8 memsz 0x000011a8 flags rwx
DYNAMIC off 0x00001140 vaddr 0x00001140 paddr 0x00001140 align 2**2
filesz 0x00000058 memsz 0x00000058 flags rw-
EH_FRAME off 0x000000f4 vaddr 0x000000f4 paddr 0x000000f4 align 2**2
filesz 0x00000014 memsz 0x00000014 flags r--
Dynamic Section:
HASH 0x00000094
STRTAB 0x000000c8
SYMTAB 0x000000a8
STRSZ 0x00000006
SYMENT 0x00000010
Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 00000014 00000094 00000094 00000094 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00000020 000000a8 000000a8 000000a8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 00000006 000000c8 000000c8 000000c8 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .text 00000024 000000d0 000000d0 000000d0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .eh_frame_hdr 00000014 000000f4 000000f4 000000f4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .eh_frame 00000038 00000108 00000108 00000108 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .dynamic 00000058 00001140 00001140 00001140 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .got 00000010 00001198 00001198 00001198 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .comment 00000011 00000000 00000000 000011a8 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000094 l d .hash 00000000 .hash
000000a8 l d .dynsym 00000000 .dynsym
000000c8 l d .dynstr 00000000 .dynstr
000000d0 l d .text 00000000 .text
000000f4 l d .eh_frame_hdr 00000000 .eh_frame_hdr
00000108 l d .eh_frame 00000000 .eh_frame
00001140 l d .dynamic 00000000 .dynamic
00001198 l d .got 00000000 .got
00000000 l d .comment 00000000 .comment
00000000 l df *ABS* 00000000 helloworld.c
00000000 l df *ABS* 00000000
00001140 l O .dynamic 00000000 _DYNAMIC
000000f4 l .eh_frame_hdr 00000000 __GNU_EH_FRAME_HDR
0000119c l O .got 00000000 _GLOBAL_OFFSET_TABLE_
000000d0 g F .text 00000024 main
(Note the missing second LOAD program header for data).
I’ll try to have a look at fixing it but did not yet have any luck fixing it. Maybe someone could have a look at that who has more knowledge about binutils than I do.
kind regards,
zeldakatze
1 Like