Honestly, compared to C/C++, Rust is pretty great. Obviously i’m not pushing to start rewriting Haiku in it (though, it sounds like the Linux kernel has been playing with the idea), it is a fun language.
That function downloads the binary blobs, and copies them into the fat32 boot partition of the Haiku sd card in a platform agnostic way. It’s like 90 lines 
I heard that Rust have a problem with error handling (standard library often terminate process without of chance of handling, problems with exception handling). Also I head that it have a problem with arrays.
Yup. This was an earlier problem though. Rust solved it with the introduction of the magic ?.
? is essentially an automatic inline unwrap with error checking and return.
You could be 20 functions deep, and if every function uses ? on the result you can bubble errors up.
Ex:
let thing = thing()?;
is the equivalence of:
let thing = thing();
if thing.isErr() {
// thing is Err(reasoninfo); bubble the error up.
return thing;
} else {
// thing is Ok(thingresult); strip off the "Ok wrapper" and continue
thing = thing.unwrap();
}
more info if you care 
Error handling in Rust
To each their own thing. Personally I don’t find it readable, but maybe that’s mainly because I spent 15+ years writing C and C++ and it’s hard to adjust to anything else. I think it started well with a nice and simple language, but then it was shaped around the constraints of their ownership checks, and in the end it is full of shorthand notations that seems difficult to understand to me.
Not saying it’s a bad language or anything like that, really it’s just a personal opinion.
On the side of Haiku, all the OS and the tooling around it is written in C++ and we don’t plan to change that, even if it’s possibly not the best language to use anymore. It is hard enough to know one language, so it would be nice to keep it down to that. But again, this just means I won’t be the one maintaining Rune and if I am to integrate this in Haiku or its buildsystem, I would probably write a similar tool in C++. But I have no plans to do that anyway. So, back to kernel stuff which is what I worry about for now. Let’s get this kernel starting
This is 100% fair. Honestly, from the standpoint of developing towards physical boards… if you can run the rune binary, it is pretty simple and automatic. rune doesn’t tamper with our bootloader, etc… it just injects the bits u-boot needs to get started on the target board. u-boot has the FDT within it… so once rune makes a working board it is 100% reproducible.
report any bugs / enhancements on trac and myself, @nielx, or a few other folk can take a look.
Something something wizard of oz don’t look behind the curtain.
And of course after all my swooning, rune isn’t currently working on our latest images 
I’ll take a look at #17659 (EFI fat filesystem prepared by new internal filesystem tool invalid) – Haiku in a bit.
As promised, back to lowlevel kernel/bootloader hacking…
Yesterday I tried to add some traces to the kernel_entry function.
To do this I hardcoded the address of the UART TX register, and I write bytes there at various steps of the function (it is written in assembly). I get a fault right after configuring the MMU. In the page table dump I see the UART is not mapped anymore, so maybe my debug traces are making things crash. I was investigating if it’s possible to keep the UART identity mapped when activating the MMU, so that we can continue to get logging.
On RISC-V I gracefully handle virtual mapping by replacing physical address with virtual on mapping: mmu.cpp\riscv\platform\boot\system\src - haiku - Haiku's main repository. Storing physical device addresses in kernel args is not needed because it can be acquired by walking page translation table.
Perhaps it may be a good idea to add support for the PINE A64-LTS and ROCKPro64 SBCs from PINE64, too. The former could also help enable support for other products based on it such as the Pinebook, SOPine (baseboard), PineTab, and PinePhone; support for the latter may also be useful for enabling the Pinebook Pro as well.
good to see the renewed interest in both 32-bit and 64-bit ARM ports.
I still have a few patches that I’d like to clean up and submit this week.
After that, perhaps it’s time for me to wire up the raspberry pi 3 with the FTDI cable and see what comes out of it.
Maybe some more sophisticated logic will be needed for UART selection in the FDT logic. (e.g. /chosen node, additional uart drivers etc.)
yep, PineBook Pro / RockPro64 also seems to be a good target
i took a brief look at the device tree for mk802ii in u-boot github repo, probably we’ll need a new UART driver.
currently there’s supposed to be support for pl011 and 8250 but i only tested the pl011
edit: i just noticed there’s something there already for this
we might still need to add the /chosen handling
The uart is compatible with the 16550 which itself is compatible with the 8250 (confirmed by checking the datasheet for it). I added the “compatible” entry to the bootloader to initialize it using the 8250 code and it is working fine there.
so is it able to find the correct uart with the current dtb code, without fdt chosen node handling?
Yes, it’s finding an UART, not sure how it picks it, maybe it just picks the first one?
The only thing I had to fix on FDT side was hardcoded address-cells and size-cells values: https://git.haiku-os.org/haiku/commit/?id=ef410594320fecf8ea59196f76b8b18b91696b38 (on my hardware both should be 1 and they were hardcoded to 2, now they are read from the device tree)
And to get the UART going: https://git.haiku-os.org/haiku/commit/?id=2d80f9e236137efa476cc6d32cda21dcda1c0ffb
Yes, it picks the first one with a known “compatible” string.
In a lucky scenario that is a good candidate for a debug output. It’s a bit more complicated on the raspberry pi as the first UART is not usable and we have to use the second UART which is the ‘mini-UART’.
Unfortunately there’s some more to the address-cells/size-cells handling in FDT as it can define different cell sizes on different levels of the tree.
e.g. the RPI4 has address-cells=2 on the root but address-cells=1 on the /soc subtree.
some testing on raspberry pi 3b+ & 4b…
rpi3b+:
the mmc image generated by rune command is not bootable on the rpi3 as it doesn’t recognize the fat partition.
we need to remove the “esp” flag, e.g. with parted:
parted /dev/mmcblabla set 1 esp off
then it boots up and the mini-UART is detected from FDT /chosen/stdout-path node. (review pending)
the bootloader is in hypervisor mode so we have to do a PL2>PL1 transition, similarly to the EL2>EL1 transition on the arm64. I have an initial implementation of that which works on qemu (with -M virt,virtualization=on) but it’s not quite right on the rpi3 yet.
rpi4b:
the current u-boot binary in haiku firmware repo is not able to read from the SD card, so I had to rebuild a newer u-boot.
there’s also no /chosen/stdout-path node in FDT so the mini-UART is not recognized.
workaround: if I comment out the pl011 driver then the mini-UART gets detected
similarly to rpi3, the bootloader is running in hypervisor mode on the rpi4 as well, so the PL2>PL1 transition will be needed here as well.
until then, we can enjoy the splash screen, with all the icons dimmed out
@kallisti5 may can update rune u-boot image.
For RPi4 I planned to follow this setup: https://github.com/pftf/RPi4#installation
Do you mean rune is unable to recognize the ESP partition or the raspberry pi 3 doesn’t recognize the EFI System Partition?
There was a bug in rune that was fixed in the 0.1.1 release. Make sure you’re using the latest version Release Rune v0.1.1 · haiku/rune · GitHub
If the Raspberry Pi 3 refuses to load u-boot and start.bin from a EFI System Partition (0xef), and requires a Windows 98 Fat (0x0b), that’s something we’re going to have to add to rune. Luckily it isn’t too difficult since rune can natively manipulate file-systems and partitions
So, the u-boot binaries in the firmware repo are based on stock u-boot sources. The readme for each u-boot binary shows the compile date / time / revision. In the case of the Raspberry Pi 4…
Last Update: Mon Dec 28 08:39:15 PM CST 2020
Definitely overdue. The build process is pretty simple @davidkaroly if you want to give it a try.
git clone https://github.com/haiku/firmware
cd firmware/u-boot
# if you want to use haiku's gcc toolchain..
# export PATH=$PATH:blah/generated.arm/cross-tools-arm/bin/
tools/build arm rpi4
The build script will take care of generating the README, grabbing the required binaries, etc. You can omit the “rpi4” to rebuild all of the arm firmware, but i generally only build individual firmware so they can be tested / validated.