I wonder why? Maybe it’s because on these, you can actually run and use Haiku?
I’d like to see the 680x0 port gain traction.
But that would only be because I want to run Haiku in a VM, running Hatari emulating an Atari Falcon running Haiku running Atari800.
Well for 68k you’d need ARAnyM anyway as Hatari doesn’t emulate the MMU I think.
I thought it did, but I suspect you would know better than I would. The other problem is that I can’t get Hatari to emulate a Falcon (or TT) because it complains about not having a renderer.
“I love the whole concept of Haiku and would love to see it run on embedded hardware like all these planned linux+arm netbooks. Since ARM-CPUs are used in so many different devices and most of these devices are multimedia devices like netbooks/mediaplayers/smartphones it would make sense to port Haiku as an multimedia OS to these devices.”
NOTE: This is the same subject matter being discussed and explained there in the commentaries. History repeating…
Then, this page still remains:
" Haiku builds for several computer architectures, below is a list of each architecture with additional information. The interest column does not reflect any architecture preference by the Haiku project, only current real-world developer interest."
Quoth the Raven “Nevermore.”
I’am look to source of linux kernel 3.x folder with ARM and I was shocked. Many od clone architecture of ARM. I see that the producers write their own single board software.
My question is a what architecture is real importent in Haiku-OS?
I selected a 3 core of this:
And that about 64bit it’s other architecture then ARM?
Basically, the Cortex A72 is sufficient and cost-effective.
I recently fixed some stuff on the m68k port, some still pending review.
As a reminder, we also accept patches. You can help porting to other architectures as well.
Well, Amiga 1200 does a 68E20 without MMU, only a full of version 68030 does a mmu.
I wonder how Haiku work on 2 MB CHIP + mayby 4 MB FAST, what a memory deficit on Amiga system? How do you work it out?
My current Amiga setup is an Amiga 4000 with a 68040 and 130MB of RAM (2MB chip + 128MB fast). That may be a reasonable target for Haiku (it will be slow, but we do this just for fun). A plain A1200 is definitely not a reasonable setup for Haiku.
The problem is what you have mentioned are CPU architectures… not system architectures, and you also have to support those. So… supporting the different CPUs isn’t too difficult but then you run into having to support a separate BSP for each different board since there is no unified ARM architecture.
ARM really will never be suitable. PPC and x86 on the other hand are suitable as they both have a well defined architecture. Sparc also fits in there mostly, however it is only made for servers these days but it could return theoretically.
I’m still waiting for the Z80 port.
Raspberry Pi is a good target for Haiku. It is cheap, massively available and has 32/64 bit support. Raspberry Pi has UEFI/ACPI tables implementation (GitHub - andreiw/RaspberryPiPkg: DEPRECATED - DO NOT USE | Go here instead ->) that can be used for boot loader and hardware detection.
CPU architectures other than x86 and ARM are almost dead and primary used in legacy/domain-specific projects.
The problem with ARM, as stated is that each architecture revision is different, and most hardware is not connected with a discoverable and standardized bus like PCI on x86. Even with the FDT to describe the hardware, we still need specific drivers every time because each hardware has its own protocol, instead of supporting some basic common subsets like with PCI class, subclass and api.
It’s getting better with UEFI support but it’s still a mess.
I see no problem with ACPI table based device detection. There are little difference between PCI bus enumeration and ACPI table enumeration from driver view. Both provides hardware ID and resource table (MMIO, IRQ etc.).
Yes but it still needs a specific driver, except for devices that are “compatible” (FDTs have a property to specify this) with one which we do have a driver for.
There are also UEFI ARM notebooks available such as Lenovo - Yoga C630 (ACPI table: https://raw.githubusercontent.com/aarch64-laptops/build/master/misc/lenovo-yoga-c630/acpi/DSDT.dsl).
They still suffer from all the same problems mentioned… the arm hardware designers fail to see the importance of a consistent bus design. x86-64 is a well traveled road, by other OSes and Haiku has more problems to face than it can shake a stick at without most of the developers focusing on an alternative plaform for years without actually making much progress otherwise (by the time they port, the hardware is obsolete). Now… if you personally are interested by all means join up with the few other developers working on ports for fun and go for it, just try to not drag all of them into the fray.
The main problem with ARM is, if you want it to happen, you can submit patches. Trying to convince other developers is not how it works here (unless you can hire them).
In my case I work on SPARC because it makes things super easy to debug (the firmware allows for easy console output and gives me backtraces, that’s the least I can ask) and because I like to explore less popular architectures to learn about their strengths and weak points, and also because I received some hardware donations. And also, it’s one of the few fully open architectures (anyone can make SPARC CPUs, the OpenBoot code is open source, etc) which I think is a good thing. I do not want to reinforce the monopoly of ARM and x86 on the CPU architectures market, and I think technodiversity is good (otherwise I would not be working on Haiku but on Windows or Linux, following the same reasoning).
I personally treat Haiku as a hobby that takes more and more time for me. I know that money does wonders, but I would focus on the open source community and movement. Where bounty or dotations do wonders. It all depends on the community.
As for ARM, I see that the Haiku port requires virtually as much time and resources as to create a new operating system.