It is the version required in haikuports, it was the only repository it had, if necessary, avoid random repositories, so we should create a repository to store these sources or find alternatives.
Sorry, not following here? 
I post a link to the netpbm source, the question is whether the link is random, should we save the sources in our own repository or find alternatives.
The netpbm recipe was adjusted to use the official sources from the netpbm repository, which is an older version they offer a download for. There is no need to search for “alternatives” here, either there is a version that is released from the official source with an usable download, or there isn’t.
This problem being solved, let’s see how far the build will get now…
2 Likes
I’m talking in general, about the dead links, which are on haikuports, where the sources are not on the official websites or are found in random repositories!
We therefore need to maintain intelligent solutions to avoid revenue problems, as there is no point in having old software, with construction problems.
BuildHaikuImage1 haiku-bootstrap.image
Creating image ...
Creating filesystem indices...
Populating image ...
Unmounting ...
...updated 566 target(s)...
Ok, that part of the bootstrap is now complete 
Now, let’s see if I can actually boot this into qemu, far enough to run haikuporter?
5 Likes
Hope that works out ok, biggest challenge at the start of that is the “updating dependencies” 
Well, before I get there I have to figure out how to boot the image!
One option that may have a chance of working (since I’m doing this for PowerPC and we don’t have finished driver for some variants of it) is using a mostly virtio-based system to limit the number of drivers to write.
QEMU has just such a thing, the ppce500 platform. However, it comes with a U-Boot bootloader that doesn’t include EFI booting. So that means the easy way of loading the Haiku kernel with bootefi will not be available. Only bootm, bootz, bootelf and bootvx.
Alternatively I could try to configure QEMU to be a Macintosh with a G4 CPU, and try to use OpenBIOS as an OpenFirmware loader. But then, I have to build a disk image in the suitable format (not the raw one I currently have). Whereas for uboot I think I can “sideload” the bootloader using the -kernel option to qemu, maybe (or some other option).
Well I think I will leave it at that point, and hope someone with actual knowledge of PowerPC machines can step in
8 Likes
At least a few things learned (and great topic on the matter) and a few things fixed. Thanks there! 
3 Likes
If I recall, there is no efi bootloader for PPC, only open firmware. This means that one would need to go with the option 2. But perhaps building a disk image would not be needed, I think extracting boot loader from built package and creating a simple boot cd image could be enough perhaps.
1 Like
Yes, there currently isn’t, but that could be added. The only reason it doesn’t exist is the lack of platform to test it with.
And also it’s not only open firmware: @mmu_man has been working on support for the Sam440ex (which uses U-Boot, but no EFI because it’s an old version), and also the BeBox, which is something else entirely. I think both of these are less advanced than the OpenFirmware one, but then there is a bug report on Haiku bugtracker saying that the OpenFirmware loader may not actually work with OpenBIOS: #6071 (ppc: OpenFirmware boot loader hangs on QEMU) – Haiku so I’m not sure if that is a good way forward either.
As I said, time for the people who know a bit about PowerPC to join in
2 Likes
Yes, there seems to be code for u-boot loader in the tree, but it is not build with the bootstrap image, and it seems that build system only builds Open Firmware loader for PPC, and I have no idea how to build the u-boot loader.
The OpenFirmware loader might be broken on OpenBios, and perhaps on other OF implementations too, last time I played with it it reported some error regarding MMU if I recall.
Not implying that you should continue with that, I’ll just write my observations here, so if anyone with proper knowledge and inspiration to continue fixing PPC build comes along, they do not need to dig everything themselves. I wish I knew enough to fix it, It would be a nice project, although I think the ship for PPC has sailed a long ago, I still have a soft spot for the platform and some hardware I’d love to run Haiku on.
Using ARC firmware instead of Openfirmware may have better results.
“What developer Rairii – who calls himself Wack0 on Github – has done is ported a version of the PowerPC ARC firmware, plus a loader to get it into RAM, and some basic drivers to bring up keyboard, mouse, IDE and a framebuffer to certain models of Apple gear: the tray-loading iMac G3, PowerMac G3 “Blue and White”, PowerBook G3 “Lombard”, and PowerMac G4 “Yikes”. This is a remarkable achievement: while he’s taken code from several other projects, including OpenBIOS and Coreboot, this is still a hugely impressive effort.”
I posted links to build ARC firmware:
I don’t see how switching to an even more obscure firmware that Haiku has no support for whatsoever could possibly help.
We have an openfirmware bootloader that has a chance of working (with maybe a few patches on openbios), and we have an EFI loader that has chances of working in U-boot. Why would we go through the trouble of:
- Compiling another firmware that isn’t part of the things supported by QEMU
- Writing a completely new backend for Haiku bootloader, making sure we generate an executable in the proper format, that we can print text to the screen, read the keyboard, access disks, enable the MMU, switch to graphic mode and set up the bootscreen
This is a few weeks of work, for a firmware that doesn’t exist on any of the target machines by default? Why would we want to try that, when there are simpler and better documented solutions for which we have already done 99% of the work?
4 Likes
For fun, try something new and discover different solutions!
ARC firmware uses C language and closer to UEFI, Openfirmware uses Forth language.
“For the RISC machines of the 1990’s, there was an effort to rally around a common firmware
standard. An industry group referred to as Advanced RISC Computing (ARC) [6] aimed to unify
the boot environment for MIPS CPU and DEC Alpha. ARC shared some features with UEFI,
including the support of a FAT file system in the firmware, firmware boot variables, and a C-
callable interface. But ARC lacked, GPT, the extensibility of UEFI, and clear legal specification
governance or an evolution path like the UEFI Forum and UEFI specification. As a design,
another issue with ARC was that it specified platform design definitions. This design mandated
that various components must exist in a platform, thereby limiting diversity of platform
designs. Also, ARC was never ported to a volume architecture such as IA-32® or x64.
Another effort that is similar in its role to the PC/AT BIOS-based platform occurred with Open
Firmware (OF) [4] and the Common Hardware Reference Platform (CHRP). CHRP was a set of
common platform designs and hardware specifications meant to allow for interoperable designs
among PowerPC (PowerPC) platform builders. Open Firmware, also known as IEEE-1275 [4],
has issues in that it is an interpreted, stack-based byte-code. Very few programmers are facile
in Forth programming, and it is renowned as being “write-once/understand-never”, and having
poor performance, and non-standard tools. Also, Open Firmware has a device tree essentially
duplicating ACPI static tables. As such, the lack of Forth programmers, prevalence of ACPI,
and the fact that UEFI uses standard tools and works alongside ACPI—versus instead-of—
helped spell Open Firmware’s lack of growth. In fact, it is used on SPARC and PowerPC, but it
is unsuitable for high-volume machines and thus prevent it from making the leap from niche
server & workstation markets.”
NetBSD has good documentation on ARC firmware:
Hello,
I’m pretty impressed how fast you people fixed up the cross-compile environment!
Sorry for not contributing that much currently, I have to learn for some exams.
Yesterday I could not build the bootstrap, but that’s apparently because gnome’s gitlab instance had some trouble, but it seems to work now.
I’ve tried booting the openfirmware bootloader, first on Qemu by creating a hfs image with both boot_loader_openfirmware and haiku_loader.openfirmware on it.
In both cases openboot refused to boot them. However on my Powerbook it did load boot_loader_openfirmware and went to a black screen with a jittering text cursor. Once my exams are over I’ll try getting openfirmware to boot something.
kind regards,
zeldakatze
4 Likes
Hello again,
I’ve gotten boot_loader_openfirmware to load on qemu by putting it into
a disk image. I’ve created a script to quickly do this (GitHub - TheZeldakatze/createHFSfile: creates a bootable 50MB hfs image). (It is mostly copied from GitHub - thamugadi/powerpc-ofw-boot: Bootable stuff for PowerPC-based macs ).
The openfirmware loader does load, however the console is broken and doesn’t output anything. Copying the puts function from powerpc-ofw-boot, it works under qemu.
Patch
diff --git a/src/system/boot/platform/openfirmware/console.cpp b/src/system/boot/platform/openfirmware/console.cpp
index 8b743c3461..87f4a25354 100644
--- a/src/system/boot/platform/openfirmware/console.cpp
+++ b/src/system/boot/platform/openfirmware/console.cpp
@@ -95,6 +95,20 @@ Console::ReadAt(void */*cookie*/, off_t /*pos*/, void *_buffer,
return bytesTotal;
}
+void HackyPuts(char* str, int len)
+{
+ char cmd[len+8];
+ cmd[0] = '.'; cmd[1] = '"';
+ cmd[2] = ' ';
+ for (int i = 3; i < len+3; i++)
+ {
+ cmd[i] = str[i-3];
+ }
+ cmd[len+3] = '"'; cmd[len+4] = ' ';
+ cmd[len+5] = 'c'; cmd[len+6] = 'r';
+ cmd[len+7] = 0;
+ of_interpret(cmd, 0, 0, 0, 0);
+}
ssize_t
Console::WriteAt(void */*cookie*/, off_t /*pos*/, const void *buffer,
@@ -123,7 +137,9 @@ Console::WriteAt(void */*cookie*/, off_t /*pos*/, const void *buffer,
}
if (length > 0) {
- fWriteHandle.WriteAt(NULL, -1, string, length);
+ //fWriteHandle.WriteAt(NULL, -1, string, length);
+
+ HackyPuts((char*) string, length);
string += length;
bufferSize -= length;
}
@@ -131,7 +147,9 @@ Console::WriteAt(void */*cookie*/, off_t /*pos*/, const void *buffer,
if (newLine) {
// this code replaces a single '\n' with '\r\n', so it
// bumps the string/bufferSize only a single character
- fWriteHandle.WriteAt(NULL, -1, "\r\n", 2);
+ //fWriteHandle.WriteAt(NULL, -1, "\r\n", 2);
+
+ HackyPuts((char*) string, length);
string++;
bufferSize--;
}
It then errors out because there is no mapping for the exception handlers.
However the bootloader loads and outputs stuff on my real powerbook. You can briefly see the bootloader log displaying before it enters the boot menu. You can see the labels of the buttons, however the boot loader crashes shortly after. I still find it interresting that the openfirmware loader works better on real hardware than on qemu.
I’ll have another look at the console and exception handler mapping shortly.
kind regards,
zeldakatze
1 Like
This should already be done in Haiku build scripts, but you have to use the right image type (I think it is @bootstrap-cdrom instead of @bootstrap-raw). I have not tried that with the bootstrap image, however.
The entry point for that would be CDBootImage « images « jam « build - haiku - Haiku's main repository
It is more a problem of different firmwares, as qemu does not run a complete openfirmware implementation. If there is a way to run an actual Apple ROM inside QEMU, that would possibly work better, but I don’t know if that’s actually possible at all.
Otherwise, you have to figure out if similar services are available under different names, as I had to do when working on the SPARC port (also uses some variant of Open Firmware, but a few things were done differently).
I assume not much has changed since 2009:
Hello,
The console should now work, stdin and stdout were mixed up.
However the bootloader still only properly loads on real hardware, on
qemu it hangs on line 891 in mmu.cpp:
ppc_set_segment_register((void *)(i * 0x10000000), sSegments[i]);
which seems to be the external function of /cpus that is mentioned in the other thread.
I’ll have a look at how some some other bootloaders work, openbsd seems to also panic on boot
I built a bootstrap build on a clean environment (a fresh vm of debian 12)
and I’ve noticed that at least textlive seems to link against the host ncurses library.
Also there seem to be some problems with Haikuporter on a crossbuild if for example cmake is not installed. I’ll create a ticket about that soon.
kind regards,
zeldakatze
4 Likes