Because they’re dirt cheap and numerous, and there’s a huge ecosystem of compatible cases and external hardware?
5 Likes
Many pieces in computers are (nearly) always proprietary and can be used only with reverse engineering.
Wifi is a great example for that,just that we profit from FreeBSDs efforts instead of investing months of our own time to make it work.
Or graphics cards,have a look at Nouveau,it’s all made of reverse engineering because there is no other solution.
Yes,I’d also prefer open-source hardware,but it will much time until more RISC-V stuff becomes available or that PowerPC Notebook is finally finished.
2 Likes
so the fact that 40 million units have been exceeded doesn’t make it an interesting product?
even if the wifi doesn’t work, the lan works in the bsd world…
[sorry my english]
2 Likes
a NUC wouldn’t attract thousands of nerds 
I’m quite keen to try contributing towards a Raspberry Pi port. I’ve compiled up a build of Haiku for Arm, and dug out my Raspberry Pis and serial cables.
I’ve got a neat USB-C hat which provides both power to the Pi and a UART back to the host, so you can get power & serial to a Raspberry Pi with just one cable!
I’ve got about 5 or 6 Raspberry Pis here at home (3B and 4), and a Pi 400. We use quite a lot of them at work for embedded hardware projects.
Need to figure out how best to coordinate people who are interested in working on it. I can see from the forum there’s been a bit of activity over the last couple of months with 32-bit and 64-bit ARM ports. Do people tend to hang out on IRC?
7 Likes
1 Like
I do, at least sometimes. There is also this forum, the mailing list, and lately a lot of discussion for the ARM port has been in the Gerrit code reviews since David Karoly is keeping us busy there with lots of patches to review 
For the more general discussion: I’m happy to see people working on porting Haiku to whatever they want and we’ll review and merge the changes and answer any questions as they come. If you really want to see Haiku running on some hardware, the best thing to go is start hacking and make it happen. If you wait for some Big Central Haiku Authority to… I don’t know, somehow greenlight it? Put an army of developers on it? Well, it won’t happen because we just don’t have that (neither the committee, nor the army of developers). It’s more “pick some tools and join the work” here. Unless you (collectively, through a crowdfunding) have enough money to raise an army of developers, of course!
1 Like
Cheers PulkoMandy, sure thing, I don’t expect anyone to do anything for me here. I’ve got 20+ years of C++/whatever dev under my belt, I know how it rolls 
I just posted the message because I know other people have been doing some work on ARM, and:
- didn’t want to tread on someone else’s toes
- waste my own time
I’d like to start looking at a bootloader for Pi 3B (32-bit) and Pi4 (32-bit and 64-bit) and work from there…
I’ve got way too much Real Work™ to do, but it’s been burning me out a bit, and I feel like doing a little bit on this would be Fun™.
14 Likes
Considering that the RPi 3B and 4 both use ARMv8, why not just focus on a 64-bit bootloader first? Only the RPi 2 and below are exclusively 32-bit.
3 Likes
The current efforts are on using EFI to boot. This can be done from uboot now and also from some other bootloaders (not sure what’s common on the Pi). I think with uboot it is not quite working yet, and most of the testing so far was done in QEMU. And as usual we’re not so good at keeping documentation up to date 
so I’m not sure if there is a list of what works and what doesn’t and an example QEMU command line at the moment.
Possibly it’s a good idea to get David’s patches from https://review.haiku-os.org/q/topic:%2522arm%2522+status:open when testing things.
3 Likes
Normally the Raspberry needs some proprietary blobs to boot,but there’s now also a open-source UEFI firmware for it which could make booting Haiku easier: https://github.com/pftf/RPi4
The UEFI firmware already works with the BSDs and their generic AArch64 image,but I don’t think Haikus ARM port is already far enough that it could boot.
5 Likes
Maybe a little bit off-topic,but for those who want a Raspberry Pi 400 with Haiku,I just found some very cool alternatives.
They’re called Cybernet ZPC and have a similar form factor (a bit bigger,but also a whole computer in a keyboard) and have Intel x86_64 CPUs!
Unfortunately it seems they’re not manufactured anymore,but I could still find some offers on ebay.
The most recent model supports up to 8GB RAM (upgradeable) and a SATA hard disk or SSD which is also upgradeable,so that’s better than the Raspi 400 already.
It’s more expensive and doesn’t help with the Raspi 400 I already own,but for those who don’t have one yet,this may be a better choice.
The hardware is quite similar to a laptop,just without the display,so there’s a pretty good chance Haiku will run on it.
The Raspberry Pi Foundation has a page with links to hardware documentation, including datasheets and architecture reference guides:
Based on a brief glance of the page, the RPi 3 series and the RPi 2B V1.2 may be ideal targets for RPi Haiku work since they are 64-bit capable (BCM2837 SoC and variants with different frequencies) and their iGPU (Broadcom VideoCore IV) is fully documented.
3 Likes
My thoughts on ARM summed up perfectly here
1 Like
Yes, I’m pretty familiar with these. The BCM2837 is very well documented, and there’s a Mesa Vulkan implementation too, so it ties in well with various projects in flight.
I’m not convinced about using UEFI for Raspberry Pi personally. Linux, RiscOS, etc don’t use it for booting on Raspberry Pi. It looks like its mainly higher end ARM server boards which have UEFI firmware.
Uboot is pretty common for ARM SBCs, but it doesn’t support BeFS.
This post is really good,thanks.
I also wrote my opinion about ARM some weeks ago: ARM war ein Fehler!
It’s right that ARM is not a good platform and I really hope it won’t be the future of computing.
Its complete lack of standardization gives me headaches.
But ARM devices exist,I even use some (but I regret it and will buy more x86 again in future) and if we don’t try to support them as good as possible,Haiku will die together with x86 if it really comes to that point.
1 Like
I don’t like closed architectures any better than you do. Your article linked doesn’t describe why RISC-V isn’t better or worse however, so I’m only to assume that the supposed accountability between Intel and AMD is enough to satisfy you. Personally, I see WebAssembly as a way to bypass the whole instruction set argument altogether. Once it catches on outside the browser, I would hope somebody would write a custom architecture on a chip and port Wasmer to it rather than paying license fees to ARM or Intel. (Your post should have been in a separate thread, I think.)
1 Like
Lets focus a bit more on the port or the bounty?
Linux probably ran on ARM before UEFI became a open standard. It is not surprising they do something else.
UEFI is a step forward when compared to the alternatives.
It provides a standard, well documented and easy to work with. Except for device paths…
You get GPT partitions where you can have many partitions. (Extended partitions needs to go away)
You get a standard API so you can support many different SOC’s instead of doing a port for every SOC.
You get MS calling conventions and PE executables. Actually that is not so good 
And U-Boot was more focused on Linux booting and a moving target.
5 Likes
You don’t expect us to take this article seriously, do you?
1 Like
Not that I want to get in to another debate about this… the best hope for your dream is to write some Verilog/VHDL that runs WASM natively on a FPGA. That way, you don’t need a runtime. If that works, designing a chip is possible I guess. But having an FPGA emulate the processor is not the end of the world. Plenty of real world products emulate entire devices using FPGA’s, not least the MiSTer and the Analogue Pocket…
1 Like