My Haiku ARM (UEFI) port progress

tqh · March 13, 2023, 4:41pm

I think we want to support Raspberry on both 32 bit and 64 bit. It just takes time. Note that a lot of ARM hardware has come and gone since the ARM port was started so it is very much up in the air…

(For the work in progress 64 bit there were/are? issues with libs so it is currently targeting only newer arch, but that will change)

bga · March 13, 2023, 5:03pm

Honest question: Is it even worth it supporting ARM32? Other than that, the main reason I think RPi would be a killer platform to support is:

1 - It is obviously one of the most successful (if not the most successful) small computer development platform.
2 - It is a lot easier to support a well defined platform like it (few drivers to make sure are working and fewer weird interactions to worry about).
3 - There is no indication that it is not here to stay for the foreseeable future.

tqh · March 13, 2023, 5:32pm

I think so, as most ARM boards are <4 GB, 32 bit uses that memory more efficient. However I do think that ARM64 is better in the long run.

SCollins · March 13, 2023, 7:42pm

there’s so much fragmentation in the arm space, basically get a q port working and the rest will sort itself out bin time.

long term, I’d bet on risc-v, and NN

davidkaroly · March 18, 2023, 10:36am

I agree, Raspberry Pi (3 or 4) could be a good candidate for first HW platform for the ARM port. Once it starts working in qemu.

As of now it seems that the 64-bit ARM port would be better suited for ARMv8.2 i.e. Snapdragon, Exynos, Apple M1/M2 while the 32-bit ARM port for entry level ARMv7/ARMv8 devices.

davidkaroly · April 6, 2023, 6:14pm

Earlier I promised a list of next possible items for the ARM port… in case someone wants to join me in the fun.

So here we go.

driver and accelerant for qemu ramfb device - this is mostly for easier debugging in qemu, the code is mostly there I just have to clean it up and upload it for review
implement missing parts of memory management. Most important: accessed and modified bits. I can share some more details if anyone is interested
sort out FPU context save/restore. When does it have to be done and exactly how - the existing code is half-baked. Check how to do it on exceptions, context switches, setjmp/longjmp
thread handling is mostly there but it needs some testing, ensure that forking, signals, resuming syscalls really work as expected. So far I haven’t seen any particular issue with this but not much happens in user space so far.
troubleshoot remaining user mode issues. Currently most of the initial processes are able to start (incl. app_server) but we start getting unhandled page faults rather early. At this point I don’t know what is this so this will need some debugging.

Resolving these should get us quite far at least in qemu. Then for running on real hardware:

memory barriers need to be reviewed
similarly for cache and TLB maintenance
drivers, drivers, drivers

… and some optional nice-to-have items:

sort out which when to save which registers. Currently we save all registers on exceptions, context switches, signals etc - maybe some of it can be optimized based on the call convention - this needs some investigation, at least I always forget the save-by-caller, save-by-callee etc
implement TTBR split. Currently all the memory is mapped via TTBR0 so we have a page table containing both kernel and user memory. We could map lower memory via TTBR0, upper memory via TTBR1
implement LPAE, this also gives us better page permission handling (NX/PNX etc)

and then I don’t even want to mention SMP, that will be a story of its own. Once we get things running on one core…

the usual disclaimer: this is my current (very limited) understanding so please feel free to amend, criticise or completely ignore it

X512 · April 7, 2023, 3:01am

Is there some articles how ARM MMU is organized? Something like this: XV6 Virtual Memory - build a OS

Subcritical · April 7, 2023, 11:57am

I wander, to find who is interested to code in a SBC with an FPGA. Mainly CYC1000 with PI3.

We wont to give Haiku an FPGA.

At first we have a vt105 from sytse.
We use a programrbf openFPGALoader that could be ported to Haiku:

We aim to be the first to have an FPGA woking in Haiku.

davidkaroly · April 7, 2023, 2:56pm

there’s a detailed description of ARMv7 MMU in chapter 12 of the ARMv7 Architecture Reference Manual

alpopa · April 8, 2023, 7:58am

Those of us who feel completely overwhelmed by this detailed information, can start with give @davidkaroly a like.

Akakor · April 8, 2023, 6:59pm

And here’s the ARM v8 info: https://documentation-service.arm.com/static/5fad544dca04df4095c1c90c?token= (part D)

jessicah · May 3, 2023, 3:03am

I also spotted in the SerenityOS monthly update, that they have RPi3 emulation target in QEMU booting to their desktop without any apparent issues (other than they don’t have USB yet), so maybe there is something in there to help with our port?

davidkaroly · May 5, 2023, 4:35pm

I had a little bit of time recently to check on the current status of the ARM port (a few minor things merged recently)

The blue background is now reproducible on latest hrev, thanks to the fix for the framebuffer driver from X512. I’ve also added a fix to uname so now package daemon won’t try to uninstall everything at the first bootup.

Unfortunately we’re still getting random page faults (but every time so it might be related to timing or an uninitialized variable) and nothing shows up on the GUI, just the empty background. Some more troubleshooting will be needed.

KitsunePrefecture · May 5, 2023, 10:05pm

If one could implement a solution

to replace default background to a picture file as background …

… we could use - at least - old ARM tablets …

… to show up some favoured paintings in decent frames -(|8{D

davidkaroly · May 6, 2023, 6:53am

I can only repeat the usual comment: patches are welcome!

KitsunePrefecture · May 6, 2023, 10:10am

LOL … I intended this whole thing as a slight joke … 8D

(Next time I will mention it – this way - between parenthesises … :)) )

davidkaroly · July 19, 2023, 4:58pm

some more technical updates here, as I haven’t posted in a while.

As it’s noted in the monthly report by waddlesplash, there was some limited progress on the 32-bit ARM port last month:

implement memory types using TEX remap
implement MMU Accessed flag
implement MMU Modified flag

Other points of interest

no regression on QEMU, RPi3, RPi4 (i.e. it reaches the same point in the bootup sequence as before)
mutex issues seen on multiple threads, reaching the assertion mutex was not actually locked! - this was before hrev57121, ~~should be re-checked~~ , Update: on newer hrev we only get warning printouts, see below.
no input neither with virtio-input nor usb, input_server seems unresponsive
with a little bit of “cheating” I was able to get AboutSystem and LaunchBox to start, I’ll upload a screenshot soon

andreas_dr · July 19, 2023, 5:36pm

I love it!!!

davidkaroly · July 19, 2023, 5:43pm

AboutBox on QEMU ARM, I only had to modify data/launch/user on top of hrev57155

Console logs show a bunch of mutex issues and a page fault for one of the processes (not sure which one)

libroot __mutex_unlock: mutex was not actually locked!
Last message repeated 7 times.
slab memory manager: created area 0xd0001000 (6985)
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_rndis
usb_davicom:00.33.727:init_driver::ver.0.9.5
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_davicom
usb_asix:00.33.750:init_driver::ver.0.10.1
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_asix
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/pegasus
etherpci: init_driver init_driver: etherpci not found
virtio_pci: using legacy interrupt 36
no mtu feature
virtio_net: ioctl: unknown message 2716
register_domain(4, link)
libroot __mutex_unlock: mutex was not actually locked!
Last message repeated 11 times.
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x0, ip 0x0, write 0, user 1, exec 1, thread 0x33f
debug_server: Thread 831 entered the debugger: Segment violation
libroot __mutex_unlock: mutex was not actually locked!
Last message repeated 40 times.
loaded driver /boot/system/add-ons/kernel/drivers/dev/input/wacom
loaded driver /boot/system/add-ons/kernel/drivers/dev/input/usb_hid
ps2_hid: init_hardware
ps2_hid: init_driver
module: Search for bus_managers/ps2/v1 failed.
consoled: error -4 starting console.
libroot __mutex_unlock: mutex was not actually locked!
Last message repeated 123 times.
Last message repeated 211 times.
framebuffer: init_hardware()
framebuffer: init_driver()
framebuffer: publish_devices()
framebuffer: find_device()
loaded driver /boot/system/add-ons/kernel/drivers/dev/graphics/framebuffer
framebuffer find_graphics_card: no entry found for 0xbeef4000
framebuffer: framebuffer_init() completed successfully!
framebuffer: acc: framebuffer.accelerant
app_server: Finding best mode for 1024x768 (8, 60 Hz, strict) failed
app_server: Finding best mode for 800x600 (8, 60 Hz) failed
app_server: Use 1800x795 (8) instead.