Yes this is where I left it off last time. Thanks to @milek7 for all the code contributions last year.
4 Likes
I am not good at mmap setup, so I think we need someone who is…
Before implementing rest of VM code I think currently the main issue is the random corruption happening when timer interrupt is enabled. Last time I pored over interrupt handler but didn’t really find anything. Is this still happening?
2 Likes
what happened, whether there is a patch missing, gentlemen, write what is missing?
The non technical version is, a lot of work needs to be done by interested people:
- a lot of work needs to be done on the user side so apps have everything they need to run. Memory management being one of the bigger parts.
- there is a bug with timer interrupts that is problematic and needs fixing.
- The current cpu compiler setup is only for modern hardware, and we should see if we now can rebuild with older cpu config. Or just get rid of zstd.
But most important we lack people to work on it.
8 Likes
Probably should bring the discussion over here:
Rebootstrapping ARM64 is needed. We have newer gcc, and zstandard seems to have matured. I got stuck on gcc atomic handling when I tried a few weeks with gcc11, but it might work better with gcc13.
gcc has a way (libatomic) to detect and use correct functions depending on ARM64 atomic support. I think we should just focus on boards that supports the LSE extension instead of dynamic runtime detection and additional function call, but perhaps someone has arguments against that…
2 Likes
Something like this perhaps (haiku/build/jam/ArchitectureRules):
case arm64 : archFlags += -march=armv8.1-a -mno-outline-atomics ;
that might be not enough for the bootstrap packages, iirc they don’t inherit the archFlags settings
I see two ways
- build libgcc with all the LSE functions (like it’s done on all other platforms)
- don’t use LSE functions, instead use
-mno-outline-atomicseverywhere - but that might be trickier to get the correct build flags in place for all the packages - or modify toolchain defaults to use
-mno-outline-atomicsby default?
FYI I got a successful bootstrap build using the first approach (which I understand you don’t really like)
5 Likes
I don’t have a problem with it, it was just work that might not be needed, and only for a handful of older cpus. As you already done it, we can do that.
Lets update zstd to 1.5.5 and see if we can reduce march requirements then…
(My motivation is to get a desktop up, then build packages, and then we can work on improving build to support more. So I go for simplest approach where possible.)
5 Likes
Ahoy @davidkaroly and @tqh !
Do your discussion mean that you got closer to bare metal ARM* installation or “destop” still means a VM-built image ?
Can be possible that you may update status icons for ARM
on the Haiku image builds – port status page ?
Haiku bootable image builds – Port Status tables
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)
2 Likes
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.
2 Likes
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.
2 Likes
Raspbery Pi Five was released!
New processor Arm Cortex-A76 CPU and more enhanced.
2 Likes
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.)
9 Likes
PineTab V is out of stock 