I think so too…binfmt is used to determine the ARCH specific binary format to call the right ldconfig/qemu-user-static.
For me it looks like related to the qemu problems i face with aarch64 in ubuntu…only in my case i get segfault when creating the rootfs (second stage while calling ldconfig)
I need to add some more to the script, I think I know now where to solve the last issue… Forgot something… Should be ok in a couple of days…
Latest commit should be the fix for the last issue…
The build process completes ok, but I do not have time to check the result until somewhere next week. You are welcome to try it out, so I pushed the commit for you to try.
I’m also trying to use qemu to emulate the BPI-R64 MT7622. I can’t figure out what the appropriate machine spec is when I do qemu-system-aarch64 -machine help no machine I see listed seems appropriate. I’m running the qemu that’s packaged with Fedora 35, which is some version of qemu 6.1.0.
There are too much arm/arm64 devices/soc to define a machine for each. I think you can emulate a basic arm64 device but imho you cannot test soc specific functions
You could try something like this:
qemu-system-aarch64 -nographic -machine virt,gic-version=max
Here in the script I only use qemu for building the rootfs. It is indeed very generic qemu.
recently prepared uboot 2022-01 and noticed that is still not fixed in upstream 
Do you mean the uboot issue?
Yes,i thought it was sent upstream an already merged,but this is not the case
Thanks again for the support. Everything worked great with the updated script and the bpi is now up and running. We have bought another bpi and are now in the process of setting up the bpis as routers. One more question: We have updated the system with pacman -Syu. According to pacman, the kernel was also updated (pacman -Qi linux returns 5.18.1-1). However, with uname -r the old kernel (5.16.0) is still displayed. I suspect this is due to the custom kernel, which cannot be easily updated by Packman. Do you know how to update the kernel anyway? Or is there a way to make regular kernel updates as simple as possible in the sense of a rolling release? Many thanks in advance for your feedback.
Check out my new script, specifically for archlinux only. It is called buildr64arch and it does already do exactly what you describe.
You can use pacman to upgrade the linux-bpir64-git prebuild package. I keep it updated daily, if there is a new merge on the linux-rolling-stable git page, you will have it the next day. Or you could choose to build your self the same package from the AUR, using automated yay, or manually makepkg.
If you have two bpis on the same local network, setup one as router, and the second as access point. You will get smooth wifi roaming.
Thank you for your fast support. We tried both methods, the pkgmake build and the pre-build image. However uname -r still shows the version 5.16.0. after the reboot. Which version would you expect with the update? Do you have any ideas why the kernel is not being updated? Is there anything else that needs to be taken into account when mounting the partitions?
Or maybe uname -r does not show the correct kernel version? 
Because of the many differences, I started a new repository. The one you are using is called buildR64ubuntu. It was made for Ubuntu and later adapted to also create an archlinux version
The one I’m talking about is called buildR64arch. Specifically for archlinux. You need to create a new image with this new script. You will then have the abilities you mentioned. Kernel version 5.18.18
Thanks for the reply. We just tried out the new script on a brand new SD-card. Everything worked fine we just had to add a few lines to add the DNS-server - we would upload the changes later as a pull request in git. However, we get a “System hold” directly after a few hex-values when we tried to start the bpi with the new SD-card. Arch-chroot on the SD-card works. Second we tried the “ready-to-use” image but we also get the “System hold” error…
Can you post the output? I guess you get only bootrom,so bl2 (atf) not found.
Hallo Frank, enclosed the output:
> picocom v3.1 > > port is : /dev/ttyUSB0 > flowcontrol : none > baudrate is : 115200 > parity is : none > databits are : 8 > stopbits are : 1 > escape is : C-a > local echo is : no > noinit is : no > noreset is : no > hangup is : no > nolock is : no > send_cmd is : sz -vv > receive_cmd is : rz -vv -E > imap is : > omap is : > emap is : crcrlf,delbs, > logfile is : none > initstring : none > exit_after is : not set > exit is : no > > Type [C-a] [C-h] to see available commands > Terminal ready > > F0: 102B 0000 > F5: 4804 0000 > F5: 480A 0031 > F3: 4000 0036 > F2: 300C 0000 > 00: 1005 0000 > F5: 480A 0031 > F5: 480A 0031 > F3: 4000 0036 > F2: 300C 0000 > 01: 102A 0001 > 02: 1005 0000 > BP: 0000 00C0 [0001] > T0: 0000 0386 [000F] > System halt!
yes, it is bootrom only, so bootrom does not find bl2/bootheader
Sorry for my obtuseness. So you mean that the original bpi bootloader does not find the header that tells him to boot via uboot? May this be fixed by updating the atf and fip partition via the build.sh script provided in your repo? We will try out this later today.
bootrom is in hardware…this prints out what you see here till the “system halt”
it looks for bootheader (mostly part of bl2) on the different storage media (sd,emmc,nand,nor,…) and if it found it it will jump to it instead of the “halt”
so your card does not contain this boot-header, is not inserted correctly or bootswitch may prevent looking for the sdcard as bootmedium
Please continue the conversation about the new script here: [BPI-R64] Image builder Arch Linux v2 with image ready for download