I guess this could work with a gcc 8 hybrid? I forgot that “gcc4h” is no longer supported/built configuration, but I suppose that the build system still supports it?
Not really, the buildsystem supports it but the packages to download will be missing from the servers, and probably there will be other problems.
However, yes, it’s possible to set up the jamrules to use a different compiler for some parts. It will need some work to do that for the boot code however.
FWIW, the USB Armory II is an ARM PC stick, that has an optional debug board with 4 serial ports. Good for devs, so it might be worth a look.
The problem is not lack of hardware for serial ports. The Raspberry Pi, or even QEMU, has everything we need on that side. The problem is we can’t get our serial driver to work for some reason.
2 Likes
Is it possible ? Builders of the Haiku version on the ARM device for $ 25 like this
https://wiki.radxa.com/RockpiS or http://nanopi.io/nanopi-neo.html
So that only BASH can be run from some console (shell).
iT’s a microHaiku…
For the third time in a row:
The problem is not lack of hardware
The problem is developers with time and motivation to work on this.
And, Haiku is a desktop operating system. We are interested in Desktop machine. Something like the Raspberry Pi is ok-ish for this (I think it does not make a great desktop machine but you can consider it one). Something without even video output? What’s the point? Just run BSD or Linux there, that’s what they are made for.
9 Likes
What about NetTops? It’s a expassion a NUC or a micro ITX standard
Exactly. There could be any developer out there with enough time and motivation to work on supporting a ARM board that they have on their desk. But even with no ARM board but with enough time/motivation, they can support a virtual ARM board (qemu-virt) or just buy a cheap one. Obviously nothing gets done with many users/devs with thousands of ARM boards with no time or motivation to support ARM.
In my opinion, it makes sense to support the Raspberry Pi 2, 3 and 4 since they are the most popular ARM development boards on the market that can be used as a desktop computer. Any other ARM board with a HDMI output should be ok to support.
1 Like
In my opinion, it makes no sense to spend any time on Pi 1 and 2 because they are ARMv6 while everything else is ARMv7 at least, and that makes a huge difference. It’s almost a completely different port, and a more difficult one. This is the reason we had put focus on the BeagleBone Black instead, last time someone worked on the ARM port during Google Summer of Code. On the BeagleBone we could make quite some progress back then, serial port was working, framebuffer was working. But then Raspberry people came, they wanted FDT support (and rightfully so), and they broke UART and MMU support, and now we’re clueless as to what is working because we have no serial port output.
We should focus on one platform, and preferrably one that can easily be tested. The best choice for this is QEMU. Once we have this running stable, we can consider adding other devices, and make sure the reference QEMU implementation does not get broken.
Otherwise, adding support for one device will break another and we’ll never get anywhere.
3 Likes
Yes, I would agree as in to eventually support the Raspberry Pi 2 (which is btw ARMv7) and onwards rather than immediately focus on it. I believe we recently got rid of the Pi 1 and the other ARMv6 devices which were already obsoleted and weren’t going to be useful desktop devices anyway, so ideally I would go for supporting at least ARMv7 and recommending ARMv8.
The ARM UEFI + FDT idea is very interesting and it should also make it easier to provide a single ARM or ARM64 boot image supporting multiple boards rather than many boards and many boot images.
Absolutely agree.
We have a big problem at the moment. Because we have 4 architectures that Haiku should run on. It’s about ARM, PPC, SPARC, and RISCV. The main problem is with addressing variables because it is different for each architecture. So Char != Char. Porting the kernel won’t be that easy…
We have ONE architecture that Haiku SHOULD run on, and a number of others that it COULD run on once it’s working properly on X86.
2 Likes
I have no interest in running Haiku on my 16 GiB x64 system. It can do heavy lifting just fine under Linux.
I have MorphOS for my PowerPC Mac Mini and even took the power supply for it from my Core 2 Duo Mac Mini. MorphOS flies on a single-core G4.
What I need a lightweight, multithreaded OS on is ARM. I have several ARM7 systems including an Odroid XU4 with 8 cores and 2 GiB of RAM. I also have a PineBook Pro laptop running ARM8 under the AArch64 instruction set. Its a hexcore with only 2 of which being A72 cores. Linux is too heavy to run on such memory-constrained systems and such weak but numerous cores.
1 Like
I thought this was interesting. I suppose it’s good news for the future?
https://www.phoronix.com/scan.php?page=news_item&px=Arm-Panfrost-Going-Official
1 Like
Hi,
About a PPC. little endian vs. big endian. It’s posible to make effective dispatcher, who is be a switch a endians to right character?
I see a version of linux suse for power it’s a bigendian for servers. In acident (case) of Haiku is nessesery to make a G4 (apple) vision of endnian.
Haiku inherits the same API as BeOS and BeOS handled this via functions that change the endianness of data you pass to them. It is more I think that unless you have accounted for this there will be many places where stuff is broken because the multi-byte representation and the expected value will differ. You then need to go around adding in the missing conversions, or make the value not matter. I think the PPC version of BeOS mostly just didn’t need to worry about this, it was only when exchanging data that we had to delve in to the conversion functions. For example, if a serialised BMessage would have a what code that was in LE, to a BE system that would be a different value. On a fundamental level, ignoring the rest of the data, the message looks like it is invalid.
haiku kernel + drivers + qt = iot stuff, but why bother when theres tons of os already covering this need ??
ARM is the most useful objetive at this moment… it should be the priority (from 2019) …
If it is your priority, you can work on it. Your help will be welcome (even if it’s just small things like writing docs on how to compile and keeping track of what the current state is).
But complaining on the forum about what other people should be working on is not going to bring you anywhere closer to what you want.
18 Likes
Yes i know and very glad on haiku, know is limited, and is not like an order to anyone, but hey, i want to complain in a forum withouth any effect :3 is not my intention to offend, you have done a great job and i know.