It’s a bit pity this page still had not added to prepared Web+ bookmarks. I assume some users belongs to a circle that checks /awaits specific hardware but even a full architecture
(( It’s not me – as I would have another than regular x86 or x86_64 8D
I just speak up for those who would not go for to setup a build system just to check out how still far got the image buiding – Just as some of them did in case riscv64 - IO assume they were at least power users or application developers at least - I suspect/assume ))
I’m just absolutely curious - unfortunately not affected.
For ARM
I just have
– a Notion Ink ADAM tablet - I assume it won’t be a good candidate for install Haiku
– and a Sony Xperia Z1 Ultra smart mobile (Japanese inner market version – also not a good target for installing Haiku on it. Especially due to its broken display and fuzzy jumping and/or irresponsiveness of apps after boot fibished.
However on tablet the 2 GB RAM may enable to run some content presenter apps if anyhow finally will be good for its mobile basis :((…
For the time being it is nowhere near finished. It is being worked on, mostly by @davidkaroly. When some significant milestones are reached I expect someone to write an update. For ARM64, I think QEMU is the only viable way to evaluate the port status, but it crashes in boot as far as I know.
Supporting different kind of hardware is probably a long way off as that would need a lot of different drivers and people with hardware to develop those on.
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 !..
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.)
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.
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…
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
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 …
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.
))
