It’s somewhat running in qemu again after the recent fixes for reg-shift uarts.
src/tests/qemu-boot-test has a sane default config in it.
2 Likes
ok… I guess I lied. I tested with arm and not arm64.
I just pushed u-boot/arm64: Add qemu u-boot firmware · haiku/firmware@1516af1 · GitHub and https://cgit.haiku-os.org/haiku/commit/?id=ce41afe7f8250ce012ad2244a316d7add2398f28 to make my statements true 
../src/tests/qemu-boot-test arm64 bios:~/Code/firmware/u-boot/arm64/qemu/u-boot.bin haiku-mmc.image
results in u-boot starting, and haiku’s arm64 efi loader starting then immediately crashing. @tqh that should be a good jumping off point if you want to work on it 
2 Likes
Recently I got distracted by the next shiny thing (e.g. audacity) but might return to the ARM/ARM64 ports. It also depends on how much spare time I have.
4 Likes
I always used tianocore, How do you know if it is crashing immediately,? Any log messages to share…
1 Like
You need -cpu max, Cortex-A57 is not enough as it’t only ARMv8.0
5 Likes
Ah! Good call. This gets us into the kernel. 
You did some great work on this stuff @davidkaroly !
publish device: node 0xffff00000296c780, path urandom, module bus_managers/random/device_v1
unknown: [7460890: 14] Failed to decompress chunk data: Bad data
unknown: [7461203: 14] CachedDataReader::_ReadCacheLine(): Failed to read into cache (offset: 32505856, length: 65536), trying uncached read (offset: 32505856, length: 65536)
acpi: AcpiInitializeTables failed AE_NOT_FOUND
module: Search for bus_managers/pci/x86/v1 failed.
Last message repeated 8 times.
publish device: node 0xffff00000296c5a0, path net/virtio/0, module drivers/network/virtio_net/device_v1
module: Search for bus_managers/pci/x86/v1 failed.
Last message repeated 79 times.
PANIC: arch_vm_translation_map_create_map user not implemented
Welcome to Kernel Debugging Land...
Thread 14 "main2" running on CPU 0
stack trace for thread 0xe "main2"
kernel stack: 0xffff000002601000 to 0xffff000002606000
frame caller <image>:function + offset
0 ffff000002605910 (+ 352) ffffffff800cf918 <kernel_arm64> debug_call_with_fault_handler.localalias + 0x78
1 ffff000002605a70 (+ 80) ffffffff800d1128 <kernel_arm64> kernel_debugger_loop(char const*: 0xffff000002605b30 "�[`", char const*: 0xffffffff800d1544 "�@�", std::__va_list: 0x0, int32: 0) + 0xf8
2 ffff000002605ac0 (+ 112) ffffffff800d1544 <kernel_arm64> kernel_debugger_internal(char const*: 0xffff000002605bc0 "�\`", char const*: 0xffffffff800d185c "4B�SA��{Ҩ�_�d���", std::__va_list: 0x8019dbd8, int32: -1) + 0x134
3 ffff000002605b30 (+ 144) ffffffff800d185c <kernel_arm64> panic + 0x8c
4 ffff000002605bc0 (+ 288) ffffffff80164778 <kernel_arm64> arch_vm_translation_map_create_map + 0x78
5 ffff000002605ce0 (+ 48) ffffffff80153efc <kernel_arm64> VMAddressSpace<0x2605d60>::Create[clone .localalias] (int32: -65536, uint64: 0xffffffff800a6e00, uint64: 0xffff000002968cad, true, VMAddressSpace**: 0x2605f6800000000) + 0xec
6 ffff000002605d10 (+ 80) ffffffff800a6e00 <kernel_arm64> load_image_internal[clone .constprop.0] (char**&: 0xffff000002605ef0, uint64: 0xffffffff800a749c, int32: 43420859, int32: -65536, int32: 43420816, int32: -65536, uint32: 0x0 (0), int32: 0, uint32: 0x2605f90) + 0x200
7 ffff000002605d60 (+ 400) ffffffff800a749c <kernel_arm64> load_image_etc.part.0 + 0x19c
8 ffff000002605ef0 (+ 128) ffffffff8008b070 <kernel_arm64> main2(void*: 0xffff000002605fc0) + 0x150
9 ffff000002605f70 (+ 80) ffffffff800affd8 <kernel_arm64> common_thread_entry(void*: 0xffff000002605fe0) + 0x38
10 ffff000002605fc0 (+ 32) ffffffff800affa0 <kernel_arm64> common_thread_entry(void*: 0xffffffff8008af20) + 0x00
kdebug>
qemu-boot-test updated
7 Likes
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