shit. no. of course go mainline if ou can. i even hate systemd. the best i can think of now (not tried yet) is first booting 4.9 to set wakeup if poweroff, then kexec to mainline (but shipped firmware doesn't). i just have wake-on-lan working here. cramfs is obsolent but cool, why uboot loads it? linux can mount it (instead of initramfs, as it could use the 5mb unset with the factory partition table). to quickly setup a cute rootfs, just run: os=/mnt pkg=busybox-binsh if [ ! -f /sbin/apk ]; then service=http://edge.kernel.org arch=aarch64 branch=v3.24 version=3.0.6-r0 wget -T 2 $service/alpine/$branch/main/$arch/apk-tools-static-$version.apk -O - |tar -xzf - -C $os sbin/apk.static /mnt/sbin/apk.static -X $service/alpine/edge/main/ -U --allow-untrusted -p $os --initdb add $pkg $@ else apk -p $os --initdb add $pkg $@ fi #switch_root $os that is my netboot.sh

As for wifi, here's what I observe when the device is idle and being pinged from a laptop also on wifi. ``` 64 bytes from 192.168.68.66: icmp_seq=0 ttl=64 time=3182.692 ms 64 bytes from 192.168.68.66: icmp_seq=1 ttl=64 time=2182.085 ms 64 bytes from 192.168.68.66: icmp_seq=2 ttl=64 time=1181.659 ms 64 bytes from 192.168.68.66: icmp_seq=3 ttl=64 time=179.310 ms 64 bytes from 192.168.68.66: icmp_seq=4 ttl=64 time=3475.474 ms 64 bytes from 192.168.68.66: icmp_seq=5 ttl=64 time=2471.529 ms 64 bytes from 192.168.68.66: icmp_seq=6 ttl=64 time=1467.670 ms 64 bytes from 192.168.68.66: icmp_seq=7 ttl=64 time=463.009 ms 64 bytes from 192.168.68.66: icmp_seq=8 ttl=64 time=776.850 ms 64 bytes from 192.168.68.66: icmp_seq=9 ttl=64 time=10.257 ms 64 bytes from 192.168.68.66: icmp_seq=10 ttl=64 time=3492.560 ms 64 bytes from 192.168.68.66: icmp_seq=11 ttl=64 time=2491.066 ms ``` It repeats that fairly consistently, and has lower values when the device is actively doing something, eg: sending out pings to the router. It's like it only processes packets every 4 seconds. Best guess for now is some power management setting buried deep within the kernel and driver. Possibly only affecting my specific setup.

OK, I figured it out after some more poking: A recent change to afptool seems to be causing some problem. Using a specific older commit `ff93e32479183a3be0c86ff5441297cb8a7336d1` produced an image that upgrade_tool could successfully install and boot. I'll open an issue with afptool-rs but my ability to describe the problem is a bit weak: "something broke" The local workaround is below. Just FYI, not really something I'd PR and expect merged in vs an upstream fix. ``` $ git diff diff --git a/image-tools/repack-afptool-rs.sh b/image-tools/repack-afptool-rs.sh index 85bac3a..13b559e 100755 --- a/image-tools/repack-afptool-rs.sh +++ b/image-tools/repack-afptool-rs.sh @@ -168,7 +168,8 @@ build_patched_afptool() { mkdir -p "$src_dir" rsync -a --delete "$APFTOOL_RS_SRC/" "$src_dir/" elif [[ ! -d "$src_dir/.git" ]]; then - git clone --depth=1 --branch "$src_ref" "$src_url" "$src_dir" + git clone "$src_url" "$src_dir" + (cd "$src_dir" && git checkout ff93e32479183a3be0c86ff5441297cb8a7336d1) fi if ! grep -q 'RK3528_LEGACY' "$src_dir/src/pack.rs"; then ```

hi @Sancho, both modes were attempted at various times. I get them mixed up, but one is where `uf` works directly, and the other where MiniLoaderAll.bin needs to be done first. To be precise, `upgrade_tool uf <your-image>` works consistently, and `upgrade_tool uf <locally-built-image>` fails immediately after `Download Firmware Start`. I enabled logging with `upgrade_tool lg`, but not very informative: `ERROR:DownloadImage-->CheckParamPartSize failed` Basically the `parameter` partition. But the problem isn't obvious to me after unpacking both partitions and comparing `partition-metadata.txt`. ``` package-file,package-file,0x00000000,0xffffffff,0x00000800,0x00000001,0x0000009d bootloader,Image/MiniLoaderAll.bin,0x00000000,0xffffffff,0x00001000,0x000000de,0x0006e9c0 -parameter,Image/parameter.txt,0x00002000,0x00000000,0x00070000,0x00000001,0x00000180 +parameter,Image/parameter.txt,0x00002000,0x00000000,0x00070000,0x00000001,0x00000174 uboot,Image/uboot.img,0x00004000,0x00004000,0x00070800,0x00001000,0x00800000 boot,Image/boot.img,0x00080000,0x00008800,0x00870800,0x00020000,0x10000000 -rootfs,Image/rootfs.img,0x039b4fbf,0x00089000,0x10870800,0x0012ce00,0x96700000 +rootfs,Image/rootfs.img,0x039b4fbf,0x00089000,0x10870800,0x00124600,0x92300000 ``` Also attempted: flash original image, then overwrite rootfs partition directly with a WriteLBA. This had a low chance of working, and it was also unsuccessful. I'm happy to try a few more things and report back. I'll try a fresh build and check deeper for differences between the images.

@AurealNix - Firstly massive kudos to where you've got this board there will be lots of people here quite happy they can get onto a 6.18 kernel .. Well done sir. You 'll be pleased to hear I pulled my ebay listing as a result of what you and Claude achieved. I also signed up to a Claude subscription to save me being so abusive to Gemini when it doesn't meet the standard - thank you! So I just downloaded the headless image and imaged to an M.2 NVMe ... Connected the Serial cable powered on and nothing on the screen I'm afraid. So I armbian-imaged it onto an SD and everything booted fine, lots of text - I logged in and "fdisk -l" only showed my SD card. so I guess that's a negative with the NVMe ... one thing I haven't done is imaged the orangepi-4a 5.x kernel onto the NVMe to see if it boots as it might be that the boot protocol only looks on the SD - will post if I can image the 5.x onto the M.2 and get it to boot later. I've just tried to find a headset cable to test the audio port but only got a headphone cable so can't test yet - and I've seen in your git repo that you have already confirmed the audio port is good so no pressure for me unless you are still in need of testing ? Great stuff and cheers!