You missed the fact that we can’t ship binary blobs of an unknown license I mentioned above. Also, your expectation is users combine the bootloader portion and root filesystem. The problem is some SoC intermingle the bootloader portions deep within the sd card.
Honestly, i’ve spent 4-5 years stabilizing this publicly asking + begging for commentary. Why would you wait until now to complain?
In th case of allwinner A10, there are no binary blobs. It’s just uboot which comes pre-packed with SPL. I did not check how they build it, but I know u-boot is strict about GPL compliance, and if they decided it’s ok to include the SPL in the uboot binary, and let everyone redistribute it, there is no problem.
Maybe it is not the case for other architectures. Anyway, the fact that the files are distributed from our github (haiku-firmwares repo) puts us in the same situation as packing them with the other parts: we are already redistributing them.
None of the several dozens available on the site I linked. And I expect none at all. It will be either at a hardcoded position in the first few megabytes, or in a FAT partition at the start of the disk.
I complained 5 years ago when you started doing this that having it done in Rust would not be practical for integration with Haiku buildsystem. I still think it is not practical for integration with Haiku buildsystem.
Apparently you don’t want to integrate it with the buildsystem anyway and expect users to do this as some kind of post-processing step. I think this is making things more complicated than they need to be. And no, “Linux does it” is never a great reason to make things complicated 
I just added the first attempt at support for Samsung Exynos5 boards here:
quick start:
sudo curl -L https://github.com/haiku/rune/releases/download/v0.1.1/rune-0.1.1-linux-x86_64 -o
/usr/local/bin/rune && sudo chmod 755 /usr/local/bin/rune
rune -b odroid_xu3 -i haiku-master-hrev55948-arm-mmc.image /dev/sdcardMake sure to adjust /dev/sdcard to the device for your sdcard
You can also replace /dev/sdcard with an output image name if you prefer to use dd or any various image writing tools.
We don’t directly host any binary blobs. The only blobs are for u-boot and we automatically fully document the source location to comply with u-boot’s GPL terms.
Ill try soon. Thank you!
keep me posted. That first attempt is a shot in the dark and may not work… the Exynos5 SoC has a lot of weird boot requirements (more than i’ve seen before)
It will help a lot if you attach a 3.3v serial uart to your board to monitor the bootloader for issues.
https://wiki.odroid.com/accessory/development/usb_uart_kit
Ill do in the next 3 days max.
About your discussion here, I should be quiet. Because I have actually not a big clue :DDD
But interesting read.
not true at all. We need testers to confirm this stuff is viable and easy enough to use. 
As @pulkomandy un-gently pointed out, I kinda went out on a limb doing post-processing of images, but it really is the way to go. I chose Rust because we can make static binaries which run on pretty much any end user operating system (Windows,Linux,Mac OS X, Haiku) with minimal to zero dependencies.
These 32-bit arm SoC’s are complex to get bootstrapped and have a dizzying number of requirements. Any one step which is missed, or an offset changes and users are greeted with a black screen of non-booting without any messages.
If the situation changes, and we make an official release with arm, we could also pre-build popular sets of board target images via rune (haiku-r1-rpi4.img, haiku-r1-odroid_xu3.img, haiku-r1-rpi3.img, etc) which have allowable binary licensing.
With the above, we have a process which works for nightly images (making generic arm images everyone can customize), and release images which can target popular arm boards.
In the end, this makes everything easier to manage from a sysadmin standpoint, makes it cheaper on the Inc to host, lets us target boards with problematic binary blob licensing, and doesn’t add much overhead to end users.
End users need to use a tool to write the images to the SD card anyway… why not rune (which will also customize the image as it is written out)
I am your test boy Sir!!! I like tinkering around with Haiku. Cant await to do productive stuff with Haiku.
Please don’t. Haiku system images should not contain u-boot images and FDT binaries. Please don’t reproduce Linux mess and hardcoding to specific hardware. Single Haiku image with EFI boot loader should be enough for ARM because u-boot supports EFI.
If device supports USB then it is likely possible to boot regular Haiku image from USD drive and keep factory SD card image.
Not really, unfortunately.
If you have a board where uboot is embedded in flash and it is new enough, then yes, this will work. For ARM64, this will be the case on most boards. But for ARM 32bit systems, usually the uboot is on the SD card alongside other parts of the OS, making things more complicated.
The idea is to still keep things simple:
This is not a Linux problem, this is just bad designe for these boards and computers.
We may try to make an image that boots on several different machines, if they don’t happen to hardcode the same filename or the same sector number. But it will not be simple. Until then, the solution is to provide things in at least two parts: one generic rootfs, and a platform-specific boot part to create bootable media.
This will require some experimentation and as you can see in this thread there are at least two different approaches. We will try to do something that doesn’t need dozen of different copies of Haiku, of course, and also that is reasonably easy to set up for our users. No one wants to manually assemble the bootable setup, so we need to either provide something ready to use, or a tool to generate it. This is unfortunate, but not very different from writembr and makebootable on x86. We can manage to hide most of the complexity and make something nice and well-integrated.
But before we get there, we need something that boots at all on these devices
Can be done manually or by some installer software. Installer will write boot loader and modify setting if needed. No complete SD card image is needed.
There are factory installed image usually available. Making custom image is not needed. Just copy boot loader. If something goes wrong, ask user to recover factory image.
How do you run Installer if you can’t boot Haiku?
No one wants to do this manually, and no one wants to find where factory images are (if the manufacturer of the board still exists, even…).
I see no reason to make this more complicated for users than it already is.
Again, no one here says we will make custom images. The rootfs image will be standard. But you need something more to manage to boot it, and we should make that part reasonably easy and standardized (so it’s the same process no matter what your hardware is).
Run it from virtual machine or another OS. You need an OS to install Haiku anyway. SD card can be connected to virtual machine.
On x86_64 user also currently need to copy and install haiku_loader.efi manually.
Boards are usually sold with SD card. Installer can use it to install boot loader and replace OS partition with Haiku one.
What is wrong with @kallisti5 rune? It already do the job.
That is clearly not the way to go and will be replaced, so that users have to do this now is not a reason why this UX is acceptable.
(It’s somewhat easy too, we already do this for the image creationg: combining a boot loader section (with a fat image) with a system image. The same can be done with attached sd cards for specific boards)
Ideally this should be handled by Installer. Installer can find ESP partition by GUID and copy boot loader there. It can also register boot loader in EFI boot menu. It can be handled by similar way on ARM.
The ARM ecosystem is indeed a mess. Honestly, rune was a way to appease everyone in my mind.
This way, we focus on producing generic + standard architecture images that boot in qemu. Anything outside of this is “customized per board”. Having an EFI / ESP installer also fits within this model optionally.
We can’t sway ARM SoC vendors to do the right thing, and users will always want to run Haiku on random boards. (See @andreas_dr above for a good example of this ) This model solves all of our issues while avoiding infringing any SoC vendor licensing.
It took me 15 minutes to support @andreas_dr 's Odroid board above that he can immediately test with 3 steps. That seems pretty simple.
Yes it’s one way to do it. I hope I never have to look at the code because I know nothing about rust, however. But as long as someone else is taking care of it, it will do the job.