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.
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.
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.
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.
Constantly having to reverse engineer drivers every time Apple decides to re-engineer their SoC doesn’t sound so interesting to me regardless of the performance. To each his own, however.
We still have a 32-bit arm port which is arguably still closer to functionality than arm64.
if the build doesn’t get fixed arm (32-bit) might get abandoned.
According to the project lead, Apple Silicon chips still hold some kind of compatibility between versions that go back to the original iPhone. He mentions that it would be a trivial effort to port possible future M-chip iterations in a very easy way, unlike all the other mobile implementations.
I have 3 32-bit ARM SoC based SBCs but only one 64-bit AArch64 laptop. What would be needed to get the SBCs working? I looked at the code in the ticket and only noticed something about PCI Ecam, whatever that is…
Is UBoot sufficient as a bootloader? That’s what my Cubox i4p has though I suppose having custom flash for a bootloader could be repurposed if needed. I’m not terribly familiar with the SBC and SoC architectures used in these machines.
If the information is helpful, my other 2 ARM7 SBCs are a RasPi2 and an ODroid XU4.
Well UBoot isn’t very cooperative, in that it just gives a few infos before handing control to our loader, and can’t be called for extra stuff, like video framebuffer setup. This is one of the reasons it took so long to get ARM working, because we had to work around its limitations. But it’s still possible to boot with it, just not all platforms will have the boot splash or even on-screen debug messages. Some stuff is now handled with data from the FDT, and I think it should be possible to write external UBoot commands that could fill in the missing bits into the FDT in some way.