Much of the current SoC and USFF consumer models fit within current Haiku capabilities. As for the IGP, you have the baseline specs of OpenCL 2.x and OpenGL ES 3.2.
I compared a few media streaming sticks and USFF models. At $29 USD, I had 500,000 media channels with 4K video/HDR10, web browsing, etc.
There are the many variables to this, but it is highly possible to fit Haiku on very small devices with adequate RAM, high-end video graphics, and storage capabilities at a very decent price,
Except 99% of SoCs ship with binary driveres which are useless outside of android… there are some hacks to get it to work on Linux also, and Barret was taking this direction with his V/OS … but it’s compeltely impractical to port Haiku to ARM and also expect accelerated graphics at this point especially as ARM is just a fast moving target and barely has any standardization at all especially among SoCs.
There are only 2 maybe 3 mostly incomplete open source graphics drivers that might even potentially come close to having enough documentation to make it work with alot of effort and that is the freedreno and mali drivers, maybe etnaviv also. These drivers lag way behind as well as the vendors don’t comtribute to them… much like the other open source drivers did 15 years ago the ecosystem just isn’t ready.
Once again (sorry that I picked ARM an example, I have a bit of a boner for ARM as it’s part of my own distant past when RISC was still a pretty neat idea). IIRC even Intel and AMD boxes all run RISC internally at the microcode level but have a translator which converts from CISC to RISC so we get the speed of RISC with the compatibility of i386//X64.
This isn’t about the metal we’re running on so much as it is about giving Haiku a place it can call home.
A CHEAP place. An appliance place. A place where it can flourish as the OS of choice because it IS so darn good for daily computing. Somewhere it can truly shine rather than been some sort of also-ran that is a necroed version of BeOS.
I feel for BeOS - Gates and Microsoft crushed it anti-competitively as he and Balmer and whoever else is there these days are wont to do. The same happend with Lindows (I bought that too).
Microsoft only saved Apple because if it hadn’t the regulators would have come down on it like the sword of Damocles - something they ought to be doing to Facebook and Google now actually (but that it another thing.)
Consumers deserve choice.
Android is Linux without the GNU - and a huge piece of spyware that people still seem enamored with beyond anything I can comprehend. Maybe it’s because I remember a time before Google/Facebook/Amazon realised what machines could steal. A time when you switched a computer on and it came ON - it didn’t boot for 5-10-30 seconds (or minutes in some cases.)
You hit the switch and “pop”
BBC Basic © Acorn 1981
(Or whatever, I forget, it’s been a long time since I switched an Acorn machine on and the only assembler I can recall is LDA, STA and a few conditional branches. Oh and multiply/divide by shifting and bit of twos complement. Great days, not.)
Yes I really AM that old and yes I really could program in assembler. In fact, I could program in a bunch of languages - except the one that mattered, C!
Computers were appliances. They were hobbyist appliances by and large but still appliances. IBM PCs and clones were in offices as they still are now but even those things loaded with a modicum of speed (and a hard drive that you could SMART test by listening to it.)
I’m seeing a lot of “Negativity” in this thread (sorry, but it’s there). This is about as much use as Greta Thurnberg telling us that climate change is a problem. No s**t Sherlock!
It’s easy to knock something down, it’s easy to bitch about it and some people become memes by doing just that. Building something (like Haiku itself) takes a huge amount of thought and a hell of a lot of effort. Not to mention expertise.
I want to see a Haiku “stick” or a Haiku “box”. An appliance built upon this wonderful OS - an OS that has been designed to be beautiful rather than glued together with all the charm, forethought and preparation of a shart - yes Linux, I’m looking at you.
Why else would people want to run it? How else is public at large supposed to hear about it? It doesn’t have a killer app (and likely never will). Things are different from my day. We’ve moved on but some things never change. I never thought we’d see a desktop Linux never mind BSD - and yet I have both on the machine in front of me! (Both, this is the Void Linux one) run custom versions of XFCE.
I’d be better of in many respects running Windows because I have some Windows only apps that don’t (really don’t) work on WINE - and might never do. Apps - not games.
That’s crushing because the Linux versions just don’t do it as well which means I have to fire up the workstation just to do some specialist photo work, DTP and a few other oddities.
I’d rather use Haiku to free myself from the tyranny of Microsoft and other parties who now control the direction of Linux and much as I like *BSD, oh my LIFE it’s slow to boot!
I just want a machine I can flick on, write and email and flick off. No mess, no fuss, no signin… a machine that I can slip in my pocket and plug into an HDMI port… you know like the Intel compute stick - Atom based, doesn’t run Haiku… thanks to being Microscuppered.
Haiku is good, damn good, but no one in their right mind is going to blow 2, 3, 400 bucks or more on a machine that doesn’t come with a familiar Windows or Google virus. Baby Duck syndrome has a lot to answer for.
SBCs on the other hand… those are still ripe for the picking. IoT is probably going to get really popular too - we already have smart … things (if you’re prepared to sign away our privacy to Google/Amazon for your shiny gadget.)
What about a tablet? Oh wait… that’s bloody ARM again isn’t it. And oh look, Google has its grubby hands all over that too.
But again, this is somewhere Haiku (a touch version of course) could absolutely shine. That’s a lot to ask from the developers, I know, but software is useless without hardware and the current crop of software is dictating what hardware we can get our grubby mittens on.
That means either low-power X86 like Atom or ARM (ugh) although I believe there are a few boards like the Lime 2 which have completely open sourced the hard and software. I could be wrong of course.
The Freedombox project is working on this…
AND there - right there - is a project that is crying out for a good desktop complement. It’s a micro-server already but there’s no real desktop except Raspbian which is pretty “meh” if we’re honest and still has Microsoft and other closed-source vendors pulling distant strings.
Rant, rant…
So please, can we can the “we can’t because…” comments and try to be a bit more productive? Come on folks - all this “can’t” talk isn’t getting us anywhere. This was a battle cry for solutions! Let’s give Haiku to the masses!
Don’t stop… believing. Fit Haiku on compatible hardware. That’s it.
If not, get or write/port drivers for it. I have Haiku on USFF/SFF-solutions and use 2D/3D without accelerated graphics. Protrekker and other sound tools for music/audio. Didn’t cost millions.
Look at the HCL and build it from there… 
Fix the toolchain first.
I think gcc can build Haiku binary applications. It is a little hard to test though. As for building the OS. Not so good, unless it’s been fixed since the last time I tried.
Not sure what all the grumbling is about re: porting to ARM. It’s not hard to work with. It’s not some bizarre secret cult. It’s really not hat bad at all.
The only platforms which don’t have enough documentation to get started with are usually not worth porting to anyway.
I would also like to point out that U-Boot has a port for Raspbebrry Pi, for the people which are discussing that. U-Boot makes the process of loading an OS so very much easier.
The Raspberry Pi as pointed out isn’t an ARM board. It’s a VideoCore board with an ARM CPU glued to it. Other SoCs are generally more straightforward to work with. Ie no memory mapping weirdness.
Except by and large there is no standard ARM hardware still, there is no lowest common denominator for getting something running like on a PC. Most ARM systems don’t even have PCI/PCIe but run over a custom bus or fabric stil… so yes it is markedly harder to work with because of all the tiny differences. uboot is just the bootloader you still need the platform definitions per board as something like FDT https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/bus_managers/fdt/fdt.cpp
On a PC it almost always at least boots to a desktop, because none of the stuff required to do that has changed in an eternity, some things have come and gone like SCSI/IDE/SATA/NVMe but they all do basically the same thing.
I was going to mention fdt but I ran out of time.
Yes, there can be massive differences between hardware. That’s true. They do require per board support. However most things out there are various IP cores copy pasted together into an SoC. Generally speaking they are a fairly small set of different components.
The core system (CPU, GIC, MMU) and some peripherals such as UART use common families of components. In many cases straight from the ARM reference design.
ARM generally uses memory mapped IO which really simplifies hardware control.m
e: While I’m here, which licenses are compatible with Haiku? Pretty sure most of the hard stuff has already been done.
Why not FPGA?
If ‘pkgman install haikuporter’…
You can find a nice list under /system/data/licenses.
Have you look at things like the Asus Transformer or Sharp NetWalker series:
https://jp.sharp/netwalker/
I like these ‘all-in-one’ portable concepts better than the Pi… 
No I’ve never seen those but they don’t seem any different from any other ARM device… which means they are slightly different in many ways from every other arm device which was my point.
I wanted an OpenPandora once, but ended up getting a GPD Win I haven’t used much last year… its too small to be practical.
I had linux running on my Transformer for a while. The kernel was really old, but the experience was generally good. But why bring that up? The Pinebook series is much newer. I really like my Pinebook 1080. For people who don’t like the Allwinner chipset I think they are releasing a rockchip based Pinebook at some point? More expensive but more powerful.
Man… if you guys put the effort into Haiku patches that you put into this thread… 
@waddlesplash upgraded us to gcc8 a few days ago. I’ve been working through the last of the regressions around the gcc 8 update around bootstrap and have solutions for most. Beginning to reach issues with “rpmalloc not compiling on random arches”, so i’ve almost got bootstrap back to the the point we saw ICU issues on arm… maybe the gcc 8 upgrade will “magically fix” those issues.
Well, now the bootstrap is back to where GCC 7 was … and the exact same ICU issue persists. So we’re right back at where we were.
Did we update binutils as well? For linker errors, that may make more sense than updating gcc?
Actually, I did briefly try updating binutils early on… no improvements. However it’s worth a shot again.
I have been trying to help on debugging #14842, also without much success. Unfortunately I feel I don’t quite understand the build system which makes troubleshooting harder for me.
The build system for Haiku itself is a bit less complex than some alternatives, but fairly flexible, Jamfiles determine what is built and typically Jamfiles are pulled in as a dependency of Jamfiles higher up in the tree etc… the best reference for how to do things in a Jamfile is to just read the ones in the Haiku tree. Also see here Haiku’s Jam is a forked and updated version of Perforce Jam https://www.perforce.com/documentation/jam-documentation
Most of the errors in that ticket are actually in the gcc build which is typically autools and Makefiles, which is wrapped by a Haikuports recipe which is somewhat similar to a gentoo portage ebuild or a slackware SlackBuild except it actually defines dependencies and such.
Error in the ticket is in the ICU build system. We run that through haikuporter, cross-compiling to Haiku, on a Linux system. I think you don’t really have to understand our build system in full for that, as it is involved at this point only in sequencing various actions from other buildsystems (building gcc, then running haikuporter for dependencies). It does provide some tools to run on Linux to help with the packaging (for example a Linux version of the “package” tool that haikuporter will eventually run), as well as some development files (minimal set of .h and stub libraries so ICU and other Haiku dependencies can be built and linked).
Despite #14842 being closed, I still face issues while cross compiling for ARM.
First I was getting a lib not found error while linking ICU, which I was able to hack by creating a symbolic link named libicu-le-hb.so pointing to libicule.so.57.1 .
Now I am getting the familiar “unresolvable R_ARM_REL32 relocation” error while linking libbe.so . Seems I need to create a build dependency to gcc_syslibs_devel. Does this need to be done on the Jam scripts inside the haiku source tree?