the data aborts were caused by a TLS initialization issue… TLS pointer was not set when initially entering user space (only on context switch) so launch_daemon was trying to read from address 0x10.
once I add TLS initialization to arch_enter_userspace, the initialization sequence can proceed further.
launch_daemon spawns a few processes like debug_server, mount_server, autologin.
then we get a loop of prefetch aborts, trying to execute unmapped address
Exception: Prefetch Abort
R00=185c1290 R01=0000004f R02=00000001 R03=00000002
R04=0000031a R05=ffffffff R06=185bf360 R07=72073a30
R08=72073bb0 R09=72073c70 R10=72073be0 R11=72073b98
R12=026edb84 SP=8221ef8c LR=0262aa04 PC=01a02a1c CPSR=60000050
thread: worker
vm_soft_fault: va 0x1a02000 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x1a02a1c, ip 0x1a02a1c, write 0, user 1, exec 1, thread 0x317
thread_hit_serious_debug_event(): Failed to install debugger: thread: 791: Bad port ID
maybe it’s time to do something with the user mode debugger, e.g. resolve image name, relative offset, symbol name as it’s getting increasingly difficult to track these manually when we have multiple threads.
it’s located in functions arch_arm_data_abort() and arch_arm_prefetch_abort() in src/system/kernel/arch/arm/arch_int.cpp
we get KDL if there’s an exception in kernel mode.
it seems that the user mode debugger is not implemented so in case of a user mode exception, we get a loop of exception printouts
that’s what I was doing so far manually - based on debug printouts from runtime loader
that was easy when there was only one address space and one thread (runtime_loader early initialization, library load/init etc)
maybe the symbol lookup can be adapted from riscv arch_debugger.cpp
Yesterday I tried to run the ARM port (using sources currently in trunk) on a mk802ii computer-on-a-stick with Allwinner A10 CPU.
I got haiku_loader running without too much problems. It detects the boot partition. However, after setting up the splash screen I get no output at all on serial port or on-screen console. I guess I need to enable more tracing to see if it manages to start the kernel, and where things go wrong.
First round of patches pushed to Gerrit. Added support for the UART (easy) and for the interrupt controller (probably the init method needs to be completed a bit).
The device tree code was hardcoding address-cells and size-cells to 2 so it would only work for devices with 64bit physical addressing.
With these things fixed I get to the “enter_kernel” debug log. But I never get any message from the kernel. Not sure how I can solve that on real hardware, probably I need to do some very simple access to the UART to display some chars as I boot?
That’s so complicated! Compiling a rust app, putting my uboot somewhere online so the app can redownload it, and writing a json file, when all I need is a dd command?
I just downloaded a premade image from https://sd-card-images.johang.se and added a partition for my Haiku rootfs. Eventually I needed to recompile uboot because I needed a quirk to avoid a problem with broken EDID data in the display I’m testing with, but reflashing it was just a dd command, pretty easy.
I have also packaged the u-boot binary in Haikuports (only for the mk802ii so far, but other SoCs can be added), and I will try to integrate it into writembr so we can directly generate bootable sdcard images without a tool written in Rust being involved.
lol… technically and factually inaccurate. You have to know at what offset to dd the u-boot SPL image to per SoC. Every SoC is unique like a gentle snowflake. After we pre-load manifest.json with our known boards, users just install the rune tool once and run it. All you need is rune.
manifest.json is read live by the app from github via https
I think you’re missing the mark here. Not everyone who wants to run Haiku on ARM boards will be running Haiku as their primary desktop. There are going to be a lot of people who want to play with Haiku on ARM/ARM64 running Windows, Linux, OS X, etc.
Rune compiles and can be run on any of these operating systems. Users:
Install rune
Download our generic arm image
Write the generic arm image to the sd card via rune which customizes it for their board on the fly
That is kinda the problem rune solves. Each board has to be investigated, and a new u-boot needs compiled for each one (each SoC (arm cpu vendor) bootstraps in a different way). I’ve automated 99% of this. Fedora does something similar, i completely stole the idea from them and re-implemented it for Haiku better
Still 10x too complicated for users (and even for developers like me). We will have to integrate this somehow into the Haiku buildsystem, and provide pre-built images.
I don’t see this happening as long as the tool is written in Rust.
But I can copypaste the instructions from there too:
wget http://ftp.sd-card-images.johang.se/boots/2022-03-01/boot-mk802ii.bin.gz
wget http://ftp.sd-card-images.johang.se/debians/2022-03-11/debian-bookworm-armhf-eid4ju.bin.gz
zcat boot-mk802ii.bin.gz debian-bookworm-armhf-eid4ju.bin.gz > sd-card.img
dd if=sd-card.img of=/dev/sdXXX # ...where /dev/sdXXX is your SD card
As you can see, no custom tools, no offsets, no snowflakes. No json files to mess with either. Simple. Always the same commands for all boards, just replace the “boot” archive with a different one as needed. I don’t need to know anything about the boot layout to use this.
no. We can’t build nightly images at 300-400MiB each for 40 different arm boards.
I’m sorry @pulkomandy, you’re flat-out-wrong here. There is a reason everyone does it like this.
Here’s the example for the Samsung SoC used by the Odroid XU4:
We’re downloading binary blobs and packing them on our SD card. From a legal / license standpoint we can’t release Samsung blobs in our images.
The end users have to do it. That’s what rune is for, it’s turn-key and easy.
You have not looked at what I linked/wrote (twice now). There is nowhere a 300-400MiB file for each board. The rootfs is the same for all boards. That’s the point.
There are TWO parts to the image on this site. One is a rootfs. Just the rootfs (like our raw image). The other is just a few megabytes big and contains everything that goes before the rootfs: uboot, EFI system partition, whatever is needed to get the board booting.
For users this is very simple: just paste these two things together, and you get a working image. No custom tool needed on the user side. No complications. Instructions are always the same and use only well-known tools with nothing special to set up. If you have wget, zcat, and dd, you’re all set.
For us this is very easy to build: a raw image (we already know how to do this) and a separate, very small, but already prepared boot file.
