Please focus on other architecture like ARM or PPC

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.

Dunno if someone is interested in or can help in any way, btw Asahi Linux (aka Linux on Apple’s M1 Macs) progresses/findings sounds interesting:

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.

1 Like

Psst… If anyone wants to contribute to Haiku, and also wants the arm (32-bit) port to progress, see https://dev.haiku-os.org/ticket/17309

That one would be a good opportunity for new contributors :wink:

2 Likes

Thought it was decided a while back to focus only on AArch54 for ARM?

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.

1 Like

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.

2 Likes

Forgive my ignorance but which definition of FDT are you using? Field Definition Table? Fixed Disk Table? Formal Description Techniques? :slight_smile:

1 Like

Flattened Device Tree, prolly.

2 Likes

It can be used as EFI loader. It can provide EFI GOP interface if driver is available. I managed to get GOP with u-boot on TinyEMU: My progress on real RISC-V hardware - #277 by X512.

3 Likes

Yeah but that means porting the EFI payload to that hardware anyway…

2 Likes