My Haiku ARM (UEFI) port progress

davidkaroly · September 20, 2022, 4:51pm

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

pengphei · September 21, 2022, 1:27am

Yes, These cases seem very strange.

load image (the userland application)
parse elf referring info, start kernel thread(referring to usrland app)
trigger page_fault, lookup alreadyed pages or alloc new pages for libs or images which userland app depends
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.

X512 · September 21, 2022, 2:56am

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

X512 · December 4, 2022, 10:15pm

@davidkaroly, Any progress?

davidkaroly · December 4, 2022, 11:16pm

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.

davidkaroly · March 11, 2023, 10:36pm

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

waddlesplash · March 12, 2023, 4:15am

Woah, we are in the GUI now? Epic!

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

X512 · March 12, 2023, 4:21am

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.

waddlesplash · March 12, 2023, 4:32am

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

X512 · March 12, 2023, 4:36am

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.

waddlesplash · March 12, 2023, 5:08am

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?

X512 · March 12, 2023, 5:11am

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: https://review.haiku-os.org/c/haiku/+/3986/7/src/add-ons/kernel/drivers/graphics/vesa/vesa.cpp#293.

andreas_dr · March 12, 2023, 6:28am

I love it!!!

davidkaroly · March 12, 2023, 9:04am

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)

X512 · March 12, 2023, 9:07am

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

PulkoMandy · March 13, 2023, 10:29am

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

bga · March 13, 2023, 1:12pm

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.

humdinger · March 13, 2023, 4:17pm

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

bga · March 13, 2023, 4:31pm

Ahahahahaha… If you prefer, I can go away. 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.

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)