Well, I can only speak for myself here, but here is my current situation: I have a full time job besides Haiku and that pays me well enough. I’m happy with that situation and I don’t need the money from bounties. As a result Haiku is a hobby for me currently.
This means I can set my own priorities. I don’t do this in a completely selfish way, however: I’m first of all an Haiku user and I want the OS to stay usable and relevant. Hence the focus on the web browser, on polishing the Installer, on drivers for USB devices, etc. Sometimes I also want to have some fun and play with something like SPARC. Or sometimes I’m trying to get some specific app running because I need it and I end up fixing bugs related to it.
I could consider working full-time for Haiku but I would do it only if there was a long-term, reliable income for me. Because I find working bounty by bounty or on short-term contracts a lot more stressful and I don’t like that.
And my paid job is paid well enough that I wouldn’t know what to do with the bounty money, in fact I’d probably donate it to Haiku inc or something.
Of course, other Haiku contributors are all in different situations: some of them can find the bounty model useful, some can be ok with short term contracts, etc. So, yes, one can set up a bounty and see what happens. We even have a bountysource account: https://www.bountysource.com/teams/haiku-project
I see there is a bounty up for the virtio driver, but it was not claimed and the driver is now complete. So apparently I’m not the only one not interested in bounties?
Everyone has a different vision. When I started my adventure with Haiku, he was a skill at BeOS and extended his life with new equipment.
Later, as I understood, you declared yourself as an open source system that uses (as I understood) free open source solutions.
Now everyone goes in a different direction, and everything spills out.
Adrien, you started the Spark port. In Poland, these computers are reserved for senior employees (directors), but Sun is no longer developing it on the market, you can buy such a computer. As I understand Sun provides the code, but patents bind it 100%, I do not know what will happen by the way …
That still works. You can still run BeOS applications, and you can run them on modern hardware.
Haiku was open source from the very start, in the hope that if BeOS itself continued in some way, it would be possible to merge the Haiku code with it, and nothing would be lost. We use some existing code when it suits our needs better than something we could build ourselves. Examples are ffmpeg (for all media decoding and encoding), freetype (for font rendering), webkit (for the web browser), ICU (for localization).
The common vision is still there. It does not prevent from exploring other things, too.
SPARC is an open architecture. Initially it was developped by Sun because they wanted something better than the old Motorola 68000 family for their computers. But Sun does not own SPARC, there is an independant organization that provides the specifications for the CPU architecture, and anyone can implement them.
This is put to use by Fujitsu, who makes server, and by the European Space Agency, who uses the SPARC Leon CPU (also open source) for some of their spacecratfs. Sun also did publish the source of some of their CPUs (the OpenSparc T1 and T2) under an open source license. So anyone could work from that and manufacture SPARC machines if they wanted to. There are no patents involved, and even if there were, they would already have expired by now because the architecture is more than 20 years old.
I don’t understand what you mean by “consistent bus design”. If you mean PCI, then PCI bus is also available for ARM CPU (sample hardware: Benchmarks Of The 24-Core ARM Socionext 96Boards Developerbox - Phoronix). On x86 many hardware are not enumerated by PCI bus and some other enumeration method is used such as ACPI. For example on my x86 tablet touchscreen, pen sensor, audio adapter are enumerated only by ACPI. Many new x86 hardware have internal non-PCI enumerated devices.
I think the idea is there is no such thing as a “x86” version of Haiku. There is a version for PC compatible hardware, which means not only x86, but also a PCI bus, a VESA BIOS or an EFI providing a framebuffer, an EHCI or XHCI USB system, etc. There isn’t really a similar platform based on an ARM CPU. It’s possible to make one, but currently we just have a very diverse ecosystem of platforms there.
ARM’s been stuck for a little while. Our u-boot haiku_loader.ub locks up early on… and I haven’t really been able to figure out why (i’m way over my head at this level). Without serial / debug output, troubleshooting is limited to commenting out code, shuffling it around trying to get output, gdb attached to qemu, or qemu’s console (which waddlesplash just told me about)
As for the ARM EFI stuff, it’s been a little while since i’ve gone over it.
Today ARM uses u-boot’s native kernel image format in our haiku_loader.ub (ignore the weird naming, our “kernel” is haiku_loader.ub which then boots Haiku + our kernel)
We have serial drivers, graphics drivers, fdt parsing code in our haiku_loader.ub bootloader.
We replicate those serial + graphics drivers in our kernel.
u-boot passes the bare minimum to our loader (fdt (inventory of devices on the booted board), initrd (floppyboot), boot flags)
The issue is u-boot’s native kernel image format doesn’t include things like “where’s the framebuffer located at” So we have to scan the provided fdt for supported graphics cards, serial devices, etc, and have drivers available to set them up and use them (all of this in our bootloader)
This is where EFI comes in. EFI provides a bunch of handy support services early in the boot process such as consoles, framebuffers, serial ports, etc we can use until we’re in our Kernel (with minimal hardware knowledge in our haiku_loader.efi)
The goal on ARM is to have u-boot start an EFI-format haiku_loader.efi. Haiku_loader then can use the EFI services, and all the drivers can live purely in the kernel.
So, we’re not looking to get rid of u-boot (it’s awesome to be honest from a “making generic arm images” standpoint) We’re just looking to toss the native u-boot kernel interface for EFI which makes our lives a lot easier. Once our EFI loader supports multiple architectures, it should reduce the work for other architectures which support EFI like arm64, riscv64, etc. (our current EFI code was written without any real “non-x86” plans in mind)
My WIP EFI multi-architecture code is here:
It’s a lot of changes… so is taking time to sort stuff into “architecture agnostic” categories.
If part of the problem with the ARM port is lack of hardware to develop and test Haiku on, perhaps it could be worth asking PINE64 for some? They have been known to give OS devs free hardware with their previous and upcoming products.
Nah, lack of ARM hardware is not an issue. I have a literal drawer filled with ARM boards now… quite a few of which should be able to run Haiku (u-boot, efi, etc) once our haiku_loader is working.
Pulkomandy is correct qemu is a good target for now. The code, processes, and tools are in place to support multiple boards with our single generic arm images… we just need developers knowledgeable about arm to lend a hand.
hm. We don’t target non-legacy gcc and UEFI at the moment.
(32-bit is gcc2, everything else is gcc8)
Not sure if any of the EFI stuff compiles under x86_gcc2. As pulkomandy said however, these changes make it at least possible. (prior efi was strictly x86_64)
