Not much to be updated there - the current status icons are more or less accurate.
Next step is moving the arm port to the new gcc-13 toolchain and redoing the bootstrap build. This is a necessary thing to get the nightly builds running again. (even though no visible change in functionality)
Gentlemen, thank you for your quite expressed answers.
I see then it is still largely under development. So this way “desktop” really means a VM - QEMU.
I was red the other thread yesterday about buildtools rebuilding necessity, when I turned back to Haiku forum from watchin’ movies.
Also I’ve seen the PRs of David about refreshing affecting packages to updated versions. These were clear.
I’m just not a developer so do not put together a buildtool environment or setup recent image in a VM to peep into booting Haiku ARM version ;))
Otherwise I followed the several developments you developers sharad about new architectures , compatibility layers , etc. and as I understood some solution(s) – invented there – got into supported versions or caused that to reorganized the master as well as some things were moved from arch specific to kernel base as those were same in the all platforms (which are under more advanced status (arm*, riscv64)) against others … e.g. like ppc.
Anyway, thanks again. Otherwise I may read some brief status as well – as it’s near regular montly report time 8D
Have fun with roll over Haiku boot on ARM !
And I wish for us : others, like @milek7 , who contributed recently to this effort - they may return back and help to roll !..
Found EDK 2 prebuilt images available for download (ARM[64], RISC-V included): Unofficial EDK2 nightly build | EDK2 Nightly Build.
I setup my own EDK2 build in Github Action here: https://github.com/tqh/edk2/blob/master/.github/workflows/ovmf.yaml
Could probably be improved to build for different architectures.
Raspbery Pi Five was released!
New processor Arm Cortex-A76 CPU and more enhanced.
I will actually send anyone who has development experience and wants to give it a shot the entire money to buy a Pinebook Pro or Pinetab2 (or even a PinetabV for the guy doing the RISC-V port) no strings attached. They’re both self contained pick up and use portable computers that have working u-boot (with full EFI support) bootloaders that are going to be available for a long time. The Pinetab2 comes with a keyboard and trackpad case. They also both have GPUs supported by the Mesa Panfrost driver. With the G52 in the Pinetab2 being fully OpenGL 3.1 (full and ES) compliant. Personally I think these would be the perfect platforms for Haiku’s development. (Also, the PinetabV is basically the VisionFive2 in a tablet form factor.)
PineTab V is out of stock 
I’m thinking of this as potentially a more fun idea for my GSoC’24 proposal than my current one; just asking if there’s enough community interest and if there’s an active mentor who can help me with this.
I’ve just got a fresh ARM64 SoC and kinda want to explore more. Recently I’ve also been embracing ARM64 for some of my personal projects as well, so a lot of fresh interest here.
Interaction between userland apps and the kernel is probably my sweet spot in the whole OS dev domain.
I believe I can tackle it since I’ve explored that part of Haiku quite a bit, half of my patches last season was related to virtual memory.
I’m not familiar with timer interrupts, so for this I probably need some further studying and a bit of help.
Is this related to ARMv8.1 atomics?
I would love to see Haiku working on a Raspberry Pi 4B, (or later model)…
From what I understand, ARM SoCs need different ways of booting, & that is why there are so few other O/S that work on them.
I guess I spent the most time with arm64 of the haiku devs. I don’t have the time to be an official mentor but I will help answer questions. I am a bit out of the loop with the current status, perhaps @davidkaroly knows as he has done most of the heavy lifting.
I’d recommend trying to build the arm64 image and see how far it goes. I am a bit concerned that it might have broken a bit over time as nobody has worked on it in a while (that I know of), so don’t worry if it doesn’t go far. The build info should be in this thread I think…
Ahoy Trung,
It is really good offer !
Me myself not really related by hardware - having no ARM powered SBCs -
I have only an old, pioneering ARM tablet : Notion Ink’s ADAM.
It may even not a goal for ARM 64 - with
Nvidia Tegra 250
Dual Core ARM Cortex-A9
Yepp 32 bit - ARM v7 instruction set 
Anyway
Choice Award !
- in any case -
… and upvote your offer !
I hope David can help you in your chosen part - as a mentor - I mean he could expend time on your mentoring. He reported lesser lately on forum, or seen committed patches from him on Gerrit – maybe some life-changing events happened or some time consuming business robbed him from Haiku development 
What ARM64 SoC do you have?
I can’t become official mentor, but I can help with ARM[64] port as I already have experience of making RISC-V port.
Nvidia Tegra 250 ← hahahahahhaah I thought we were taking the path of least resistance
Dual Core ARM Cortex-A9 ← mhhhh
Dear @pvalue ,
If you would have read my post more carefully
you could have recognized I had not wrote like I would hoping in something
ARM support on it.
Against it - this way I bolded Nvidia, 32 bit, etc, in my post …
Otherwise I’m happy I could make you laugh …
My interest is specifically in ARM64 devices with UEFI. The EDK2 project is so widespread now that most popular ARM64 devices (including some high-end phones) have some level of support. I also don’t really know much about device trees so…
I have an Orange Pi 5 Plus with a RK3588 chip. It has a port of UEFI flashed so I can theoretically run some test builds with that (if I can find a way to boot Haiku without destroying the existing Windows image), but most of the time I intend to test with QEMU-KVM.
Even if the raspberry pi is not supported on bare metal, running an arm64 version in QEMU will still be significantly faster.
We will figure some way to make it work.
In the worst case, you get a mentor who doesn’t know a lot about the specifics of the particular project, but can help you get in touch with the right people.
I could mentor this, for example, but it depends on which other proposals get accepted, and who else is mentoring, to find the optimal allocation of mentors.
Is that a problem from Haiku or for some other reasons (like general GSoC rules)? From Haiku side I think we could make you a co-mentor alongside with someone from the “official” developer team.
It wouldn’t be the first time that someone from outside the developer team is a GSoC mentor, but it didn’t always work well in previous instances (for example with a mentor disappearing in the middle of the summer without any warning). That’s why we set ourselves a rule that each student has at least one mentor from the developer team. But having multiple mentors is allowed, so for the second one we can be a bit more flexible.