I get hang errors when I try installing Haiku onto a USB3 stick in a USB3 port. It works at first, then it starts having longer and longer pauses as it’s being written to. Eventually the install just stalls permanently. This is done within Haiku. I partitioned and formatted the drive with Drive Setup, then ran the installer to create a disk I could use to do an install on a machine instead of in a VM.
Would it be possible to design and produce a Single Board Computer, made especially for HaikuOS current requirements? There are many of these boards available for many purposes. I image a crowd funded campaign could garner a couple hundred backers for such a project. What do you think? Maybe this one might work?
<< Having one Udoo Neo and toyed with it.
I like the idea of them having x86 SBC, but they are a bit expensive, because udoo wants them to have makers as target, so their boards include arduino “boards” and pinouts to comply with this. I mean they work well, but may include unwanted stuff.
1 Like
Why would one design something specifically when you can just buy an existing model?
Maybe look at Compulab (https://www.compulab.com/products/embedded-pcs/). They have reasonably priced systems and already teamed up with other open source projects (https://blog.linuxmint.com/?p=3528)
Just buy one to test, see how well Haiku runs on it, and take it from there.
1 Like
It happened on the nightly build for hrev52972. That’s the earliest build I had when I first tried making the USB installer stick. The XHCI fixes happened in hrev52966, right? So I think I’ve only ever tried it after those fixes were done.
ARM hardware is pretty interesting. A lot of people don’t want to run Haiku on their x86 devices since the bar is high there. (I have my expensive desktop/laptop setup like I like it, I don’t want to break it for native Haiku). A lot of us have (sometimes multiple) cheap Raspberry Pi like devices laying around to play with.
The Haiku ARM port is actually pretty far along. We boot into a kernel, have a generic ARM image, and have a tool to prepare/write the ARM image for various target boards (including the Raspberry Pi 3)
Development has 100% stalled though due to https://dev.haiku-os.org/ticket/14842 We’re encountering a hard-to-debug issue with our gcc toolchain on ARM which prevents compiling Haiku for ARM.
If you want to help out on ARM (and have some gcc or icu skills), please help out here 
2 Likes
ICU has no problems building for SPARC, so definitely you need skills about binutils, linker, relocations, but probably not that much about ICU.
2 Likes
Glad to hear that my Pi3 might have something else to do than play videos on TV.
I will have a peek on the ticket, though i have not the skills but might ring a bell anyway.
Compuland is a great resource, but it sort of proves the point, as there are so many options, and I am sure maybe some will work or many parts of one will work, but I am paralyzed with FUD. It would be ideal if I knew that one would work with certainty. That Mint Box is amazing!
The ODroid N2 just became available to preorder. How far along is the ARM build of Haiku? Does this page provide enough info for a dev to get started? Does it look like it has enough horsepower for Haiku? If both answers are yes, I might pick one up and see what I can do with it. My experience is almost entirely application development in C++, but taking a stab at helping bring Haiku to an arm sbc like this one might be fun.
It’s all cool, odroid is a great community and their SBCs are good, but. You say, you might “see what you can do with it”. Meaning bringing up Haiku, I guess? Here is the problem. Because Amlogic doesn’t provide TRMs (Technical Reference Manuals) on their SoCs. Turning an OS bring up into a nearly infeasible task. Of course, you might try to extract information from what is thrown by them into linux. but if linux code is documentation… then, porting Haiku or other OS, will need some hundreds of years then. Rockchip and Allwinner SoC based boards are much more attractive then, because at least those two provide some kind of documentation. And there are boards even better, by overall feature set, than odroid n2. any rk3399 based board. For example RockPro64. And this organization has announced a cute and quite powerful rk3399 laptop coming soon! which makes it even more attractive target, especially as I see, Haiku emphasizes desktop as its primary target.
2 Likes
The ARM build does not build, and even if it did, it would at best load the kernel and fail because we have no mass storage drivers, the FDT is not used anywhere near enough, and the initial boot process is a mess of platform specific code (with various parts only implemented for select platforms only, and no platform currently fully covered).
1 Like
Hi all. Do we think the Raspberry Pi or other ARM platform has enough of a community that may be interested in a lightweight but awesome operating system like Haiku, that it would be adopted widely?
If so, I’m just thinking, there’s lots of little things missing generally. If people are interested in supporting a particular platform, is it worth flagging up particular issues as of interest to those special interest groups? I.e. flag each missing item with ‘raspberrypi’ - as some of these issues won’t necessarily mention every platform that needs it by name.
It may also provide a nice target list for future student contributors, or a ‘live’ state of support for each platform.
Just an idea…
Current tickets for ARM platforms support:
https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&platform=^arm
There are not enough yet to justify splitting each board as a separate component yet, but we can easily add that.
The current blocker is #14842 in that list.
Raspbian & Libreelec are a massive target for RPi-users, as most just tinker with it in headless mode so it’s probably not being adopted widely “ever”. But RPi has an incredible amount of diy makers and coders that try a lot of stuff and being a “common” hardware may help too. As a RPi3 owner, i would like to be able to use Haiku there
Haiku for pi could be tested (slow usage) with a QEmu environment set to boot with a RPI kernel (or better said, bootstrap procedure) and a haiku image for developing and debugging intentions tho, which helps a little.
However, i guess that the stuff Pulkomandy points to it’s very hard to solve, and we know that Haiku devs (not “us” 3rd party-ers) are obviously focused on main x86 architecture.
It’s worth nothing that Intel has discontinued compute sticks. I guess they couldn’t compete with Android sticks at the low end and x86 laptops/desktops at the higher end.
AMD has an STX ryzen APU board though… I find that somewhat interesting, it can also run 3 displays VGA HDMI and displayport simultaneously. https://www.asrock.com/nettop/AMD/DeskMini%20A300%20Series/
Well, I’m working on SPARC and kallisti5 is working on RISC-V. So talk about focus…
We would do more ARM hacking if we had a clue about this problem I linked earlier. It just needs someone with a little knowledge or will to research that linking error and why it happens. Both the RISC-V and SPARC port were started to see if we would hit similar problems with them. I didn’t with the SPARC port at least, so now we are fairly sure this issue is very ARM specific, likely because of the way ARM handles PIC vs non-PIC libraries and relocations.
It may be not that hard to solve. Quite likely it is one of these issues where hours of investigation result in a 1 line fiix.
My interest in ARM is limited because the hardware is very diverse, so we have a lot of work to do to get booting on every new board. ARM64 makes a lot of things simpler in that aspect but is still far from perfect. x86 however, has a reasonable common architecture. When you support USB (standardized controllers on all PCs for the most part) and VESA (also standardized), you get a bootable and mostly usable system on most machines. There is also a significant performance difference between most PC and something very cheap like the Pi. So for me it isn’t really worth the effort as an usable system. It definitely is if you want to learn a lot about ARM and Haiku internals.
In any case, it would be great to go past this issue and work on the next things.
1 Like
Ha!, confirmed me to be wrong haha.
Oh yeah, hard in term of man-hours research, just to see that library X, needed a flag. That’s mostly a given in C++ development world of flags.
Let me ask again something stupid. When i was working with arm devices from FriendlyArm, i ended coding in a debootstraped chroot of arm (armel?) in debian, where you could get into and just ran gcc + apt commands at will instead of “arm-unknown-…-gcc” et al, all being handled for me by a qemu layer over x86. That improved development a lot, instead of having to configure the cross-platform toolchain itself on debian and change all the build files. Wouldnt that help with the case… a little?
You get a system with “known” hardware that can boot from sdcard, including having several versions of the system (beta, nightly X, nightly Y,…) just swapping that. The performance downgrade, while noticeable from a mile away, doesnt hide the good sides either.
Our buildtools support cross building already. In principle it should be very simple to buikd an Haiku:
../haiku/configure --build-cross-tools arm ../buildtools
jam -q @haiku-mmc
However, to do this, we need all the prebuilt dependencies (ICU, libsolv, bash, …). This should also be quite simple:
../configure -j4 --build-cross-tools arm ../../buildtools --bootstrap ../../haikuporter/haikuporter ../../haikuports.cross ../../haikuports
jam -q @bootstrap-raw
In principle, this builds the compiler, then all dependencies, then Haiku. However, it does not work currently. We cannot use debootstrap because we need our own compiler with our configuration and patches. And we probably missed something in that configuration. The compiler in debootstrap can compile Linux binaries, not Haiku binaries (they are similar, yet different enough).