I already did look at both EFI and kernel relocations, but it’s hard to know if the intentions is different on different platforms. For instance, do not look at ARM relocation code 
I’m to tired to start anything today though.
It’s a good thing there is plenty of docs here: GitHub - ARM-software/abi-aa: Application Binary Interface for the Arm® Architecture including ‘ELF for the Arm 64-bit Architecture’.
Implemented (copied from x86_64) the three relocation cases needed:
load kernel kernel_arm64...
maximum boot loader heap usage: 382104, currently used: 372976
kernel:
text: 0xffffffff80000000, 0x190000
data: 0xffffffff80190000, 0x7a000
entry: 0xffffffff80080168
Kernel stack at 0xffff0000023d4000
System provided memory map:
0x40000000-0x45cce000 0x0 0x7 0x8
0x45cce000-0x482a1000 0x0 0x2 0x8
0x482a1000-0x483c0000 0x0 0x1 0x8
0x483c0000-0x48420000 0x0 0x9 0x8
0x48420000-0x48430000 0x0 0x2 0x8
0x48430000-0x48460000 0x0 0x9 0x8
0x48460000-0x484e0000 0x0 0x5 0x8000000000000008
0x484e0000-0x486a0000 0x0 0x6 0x8000000000000008
0x486a0000-0x48750000 0x0 0x5 0x8000000000000008
0x48750000-0x490d9000 0x0 0x7 0x8
0x490d9000-0x4a7fb000 0x0 0x4 0x8
0x4a7fb000-0x4a827000 0x0 0x7 0x8
0x4a827000-0x4a84f000 0x0 0x4 0x8
0x4a84f000-0x4a856000 0x0 0x7 0x8
0x4a856000-0x4b644000 0x0 0x4 0x8
0x4b644000-0x4b861000 0x0 0x7 0x8
0x4b861000-0x4bc20000 0x0 0x3 0x8
0x4bc20000-0x4bdb0000 0x0 0x5 0x8000000000000008
0x4bdb0000-0x4c000000 0x0 0x6 0x8000000000000008
0x4c000000-0x4c01f000 0x0 0x7 0x8
0x4c01f000-0x4c020000 0x0 0x4 0x8
0x4c020000-0x4f76e000 0x0 0x7 0x8
0x4f76e000-0x4f78f000 0x0 0x4 0x8
0x4f78f000-0x4f7c4000 0x0 0x3 0x8
0x4f7c4000-0x4feec000 0x0 0x4 0x8
0x4feec000-0x4fef0000 0x0 0x3 0x8
0x4fef0000-0x4fff1000 0x0 0x4 0x8
0x4fff1000-0x4fffb000 0x0 0x3 0x8
0x4fffb000-0x50000000 0x0 0x4 0x8
0x4000000-0x8000000 0x0 0xb 0x8000000000000001
0x9010000-0x9011000 0x0 0xb 0x8000000000000001
Calling ExitBootServices. So long, EFI!
It might be time to look at memory mapping soon…
There is a previous attempt at the ARM64 paging attempt here that you may be able to reuse in part: haiku-jarek/src/system/kernel/arch/aarch64 at master · korli/haiku-jarek · GitHub
What is a status of that code? What is actually working?
I don’t know. The person who wrote it submitted a few parts to Gerrit, but they never posted screenshots or anything like that. It looks like at one point it may have gotten to the desktop based on the commit messages, but it was not in a state to be merged, nobody took up the task of cleaning it up, and it’s now bitrotted.
It seems to use boot loader approach similar to my haiku_loader.riscv: haiku-jarek/src/system/boot/platform/qemu-virt at master · korli/haiku-jarek · GitHub.
It also implemented boot loader abstraction of virtual memory mapping, including x86. Definitely worth to investigate.
It also have some generic kernel improvements: vm_page.cpp: use wait condition for page scrubbing · korli/haiku-jarek@d11894d · GitHub.
A few of those kernel changes I merged or implemented an equivalent since then, I think, so those would need to be checked over carefully. The bootloader stuff I did not touch at all.
Interesting:
Too bad they arent around anymore. They did a ton!
Korli is still around and doing amazing work. I think he just forked jarekpelczar’s haiku repo.
Ah ok. Apologies for the noise!
He’s the silent motor 
At one point we tried jemalloc I think but it had some issues, maybe it’d be worth trying again.
I know we tried rpmalloc last. Waiting on musl’s malloc-ng or something now.
I’am have got a error
fatal error: stdlib.h: No such file or directory
pkgman install haiku_devel
no offence i’am use a debian not haiku to compile…
