There’s a new Haiku activity report, and there’s been a lot of activity over the past two months. My pick this time is progress on the ARM port.
tqh and kallisti5 are working on the ARM port. The bootloader is now running mostly fine in UEFI mode but there is some work to be done to set up the MMU before handing control over to the kernel. There are problems related to the “hardfloat” and “softfloat” ABIs on ARM, however. Until now we had worked with the “hardfloat” ABI for Haiku, assuming floating point hardware was available (as is the case on any modern CPU we could reasonably target). However, the EFI firmware does not properly handle these registers, and this seems to result in some confusion when passing data to and from the firmware. We may need to build the bootloader in soft-float mode (not using the hardware floating point processing), but that in turn creates some difficulties with properly configuring gcc.
On 64bit ARM, the floating point support is not optional, so it may be easier to move forward with the 64bit port first.
The ARM port is important for the future, since desktop and laptop ARM hardware may become far more available than it is today.
I don’t understand 99% of this update and haiku has lost a lot of mindshare momentum but I’m glad to hear they are plugging away at it. I look forward to the day when Haiku is a viable desktop,
I’d like to see RiscOS get its act together and implement pre-emptive multitasking and port to other platforms too but this is an even bigger daydream.
With the very talented, but somewhat small developer pool Haiku has, targeting something like the Raspberry Pi 4 makes a lot of sense to me, rather than trying to support the x86/x86-64 platform. Raspberry Pi has a very low cost of entry and with a smaller fixed hardware SKU for networking, storage, USB, CPU and GPU, it narrows the target for the developers, hopefully giving them the headspace to move beyond V1.0.
Yep, I came here to say the same thing. Raspberry Pi is the perfect platform for something lightweight like Haiku.
I always thought an ARM-based heavily multicore (16+) platform would be a perfect fit for something so heavily threaded as Haiku. Something along those lines in a compact case, like a home router/modem, would make a great successor to the BeBox. Heck, with all it’s GPIO, even the Raspberry Pi is a great successor to the BeBox
These comments really need a like button!
@j-mac
RiscOS seems to have adopted the Raspberry Pi strategy. This Youtube channel is a bit 1980’s BBC in style but pretty good for covering content like this. He also has a video on Haiku running in Virtualbox.
RISC OS On Raspberry Pi
https://www.youtube.com/watch?v=oL4w3AK6Qpw
Haiku Alternative Operating System
https://www.youtube.com/watch?v=hQyMS5q5H5s
“.. a bit 1980’s BBC in style …” is the understatement of the century, which is in itself very British. I love that channel – when I have the time to listen in slow mo. He did a great debunking of active RPi heat sinks.
I watched one of his heatsink videos. It was very entertaining like a cross between Tomorrow’s World and Playschool. I spend more time watching Wayne Goss on makeup tbh than tech but he covers a lot of stuff. omg. He built a retro Mini-ITX PC using a My64 case. A Raspberry PI 400 running Haiku or the open source RiscOS would be a bit of a timewarp. My brain hurts.
As RISC OS was born to run on the ARM platform (I shed a tear when they cancelled the Phoebe), it’s no big surprise that it took little effort to get it running on the Pi. You’re nicely highlighting the problem with Haiku though. The majority (myself included) can only run Haiku as a VM as the hardware support is too limited to run it any other way. This is not a reflection on the herculean efforts the developers have put into Haiku, but rather the reality of having such a fast moving and varied hardware platform to attempt to target. Microsoft can’t keep up with the hardware market, even with their huge army of developers. They rely on 3rd parties supplying drivers that work with their OS. That’s a luxury Haiku will not enjoy.
Haiku/BeOS was all about the user experience, but if the OS doesn’t run on your hardware that’s not a great experience. I realise that moving to ARM will break the ABI promise made many years ago, but as it’s been 20 years since the last official BeOS release (I don’t count Zeta), does that promise still matter today?
According to the video posted above, if you use Haiku in its 64-bit variant, compatibility with old BeOS applications is already lost. And yet he still recommends that version for most people, which suggests most of the available software is still being updated and recompiled from source today. If that’s the case with x64 already, then it theoretically shouldn’t be a big deal to move to Arm either.
I ordered a Raspberry Pi 400 just a few days ago for the express purpose of trying out RISC OS on it and getting the full retro Archimedes experience that I never experienced in its heyday (having grown up in the U.S. with a boring old IBM PS/2 Model 30, ironically released in the same year, 1987)… Really looking forward to messing around with it. 🙂
I too just ordered a Ras pi 400. Frankly I don’t know what I wanted to do with it, but I just loved the idea of having one.
There is a very detailed teardown at:
https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-teardown-and-review
It turns out the device has a better CPU than other Rap PI 4 variants. However the screen and camera connectors are gone, and are replaced by the internal keyboard connector. And even though there is some physical room inside, it is quite an hassle to open the casing.
Anyways, I am glad I had one, and hope you have fun with yours too.
Mixing hard float and soft float, sounds like a headache requiring writing thrunking code in assembly to make it work.
I found a discussion on hardfloat and softfloat. According to this discussion hardfloat was an option with ARM v6 and exists on ARM v7. Apparerently, Linux got around all this by assuming softfloat even though the Raspberry PI with ARM v6 has hardfloat capability. Raspberry PI 1 and 2 are 32 bit only. Raspberry PI 3 and 4 and onwards have 64 bit CPUs. From other discussions it seems everyone is going all in on 64 bit support. There does seem to be a significant speed increase going to 64 bits but even Raspbian OS is in beta. The testing 64 bit kernel still has a 32 bit userland.
What do you mean? I’ve been running hard float ARMv6 on my Raspberry Pi 1 for years.
I’m just reporting what I read, Apparently, earlier versions of Raspberry os didn’t see hardfloat plus the bit about Arm v6 and v7.
https://www.raspberrypi.org/forums/viewtopic.php?t=11177
Oops. I just noticed this discussion was from 2012. I give up!
Can Haiku support fat binaries?
IIRC the ELF binary format is a fairly generic container format; I think it’s possible. Hard to remember back to BeOS days…
I’m not sure it’s necessary though, Haiku’s got a package manager, which could pull down the correct build for your system.
This is really exciting though, ARM is the only non-x86 CPU design to survive and become popular from the 80s, I’d really like to see some innovation again!
In his Youtube on the Raspberry Pi 400 Christopher Barnatt (of Explaining Computers) was really excited by the Raspberry Pi 400 form factor for the same reasons. It just brings up that sense of adventure and energy and all the other stuff in computing which were a thing like more variety and simplicity and accessibility and invention. A couple of obvious niggles aside there’s the nostalgia but also the fact something with this old school form factor and for its price (!) is really usable as a modern desktop.
With a lot more focus today on multicores and threading does anyone familiar with BeOS coding know if it’s possible to produce a compatability layer to help code porting from Windows and Linux etcetera to Haiku?
Having started on Commodore Vic-20 and Atari ST, I can easily relate to that. The “all integrated” form factor is really convenient.
That is true, only until something become inconvenient or not enough, “all integrated” form factory device configuration usually is not very easy to change.
@Kochise
Yes. Chris Barnatt was really excited about the form factor as he could just pick it up off his desk and wave it around and carry it anywhere. I have a Lenovo Thinkpad and dock and like the big button which makes it rip and go. Okay, it weighs like a box of bricks but still.
If the PI 400 had come out earlier and had more memory and a drive slot I would probably have bought that instead of a laptop, If it also had an aftermarket full size keyboard I honestly think for basic office work and playing media and browsing and stuff it would be perfect. It won’t play the latest games but if developers put their minds towards scaleability and a sense of story and adventure the PI has just enough puff to cope.
@BlackV
On the Raspberry PI website there’s a few comments about limitations. It’s a good design and done very deliberately and for good reasons to a price point. They did missed a couple of opportunities though.
8GB and M.2 slot and maybe a proper HDMI port and dump the second one for an extra USB are the obvious ones. That said PI have their reasons even if they missed a possibility or two at the board design stage. There’s also a couple of case interior design issues too whereby they could have had more space inside for expandability if a heatsink plate had been designed slightly difefrently. I don’t know if they could have exposed a bus interface given board design requirements but something like this may have been useful for expandability and grown the aftermarket. But then there’s the ever present price point. The designer had to save like mad when he was a child to buy a computer and this is why he is so motivated to keep the price low. Not every school or family is rich so this is a laudable objective I’m happy to get behind.