My Haiku ARM (UEFI) port progress

based on my limited testing - adding dprintf() in thread block and unblock:
it’s more like that thread_unblock is not called.

i changed launch_daemon config to simplify things: removed everything except registrar and autologin from system launch config.
this way registrar is able to start
autologin starts, sends a signal to launch_daemon and terminates
system launch_daemon attempts to start user launch_daemon which gets blocked inside runtimer_loader and never unblocked.

@pengphei I can confirm your observation: user threads are getting blocked in WaitForPageEvents
sometimes NotifyPageEvents get called but more often it’s not. so the blocked threads won’t wake up.

PageWriterRun::Go() might be getting blocked at some point


Yes, These cases seem very strange.

  1. load image (the userland application)
  2. parse elf referring info, start kernel thread(referring to usrland app)
  3. trigger page_fault, lookup alreadyed pages or alloc new pages for libs or images which userland app depends
  4. the kernel thread(referring to userland app) blocked (couldn’t be waked up)until we got the last page(its busy flag couldn’t be refreshed by “page writer” kernel thread ;( ) which is blocked when calling to uint32 failedPages = run.Go(); The first time run to this function.

That’s all the stages, we reached the final step (the last page loading) for userland application, then blocked.


You can try to force loading all executable segments in memory to bypass problem.


@davidkaroly, Any progress?

Haven’t looked at the ARM port recently. As I remember it looked like a race condition or dealock related to modified page handling. So the issue is not loading, it’s page writing that gets blocked.

some small steps with the ARM port:

  • there’s no deadlock, no race condition, the lockup is caused by lack of accessed/modified bit handling in MMU. Current paging method reported all pages as dirty which causes trouble. If I modify it to report that no pages are dirty, we are able to progress further in the bootup. Of course we’ll need a proper accessed/modified flag implementation.
  • alignment issue in BMessage::FindInt64
  • we need to implement fork, signals, restart syscalls


Woah, we are in the GUI now? Epic!

What’s that I see in the log about ramfb?


Probably an app_server accelerant for QEmu ramfb framebuffer device. I also implemented ramfb driver, but in boot loader: haiku/FwCfg.cpp at master · haiku/haiku · GitHub. So it can display boot menu and boot splash with icons.

Right, but what’s the difference with the framebuffer driver/accelerant?

framebuffer.accelerant expects that boot loader will pass framebuffer configuration to kernel arguments. Boot loader get this info from UEFI GOP interface. But u-boot EFI do not support QEmu ramfb device and don’t provide GOP interface.

1 Like

In that case, an additional mechanism to find the QEMU framebuffer should be added somewhere, probably, but I don’t think it needs an entirely separate driver in userland for this purpose? The ARM port already has a graphical bootsplash, doesn’t it?

If so, separate accelerant should be not required. It still can be useful to change resolution without reboot for example.

@davidkaroly may also not notice a bug in framebuffer driver that cause it to not work on non x86:

1 Like

I love it!!!

There’s a bootsplash with TianoCore but no bootsplash with u-boot.
Even with TianoCore, the framebuffer driver did not work quite well for me, probably due to the reason pointed out by X512.
So for now I’m using a ramfb driver/accelerant for testing, I’m not sure if it should be upstreamed or just keep it on my dev branch as a test tool. (I’m not sure whether I’m indecisive)


Can you try to apply this fix: framebuffer: fix NULL framebuffer address · X547/haiku@b0984af · GitHub?


why not? If it allows resolution changes at runtime that would be a nice addition for people using Haiku in QEMU in general?


Quick question. Are we considering targeting the Raspberry Pi explicitly? Because it seems to me that if we can get Haiku working well on the RPi, that would be a killer combo and a very interesting development platform. Looking forward to see this progressing further. Amazing job so far.


Quite some nerve, showing your face here again! :joy: :grin: :wave:
The forum software says your last post was 19 years ago…
SCNR :slight_smile:


Ahahahahaha… If you prefer, I can go away. :wink: I have not been posting but I am around and have been following things. Last time I showed up, I fixed a lot of ethernet drivers so I guess this might be a positive thing. :wink:


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)

1 Like