Caleb Gilmour

hi @Sancho, what worked fine for me was removing the `wrap_parameter_for_afptool` step, and having afptool-rs handle it. I looked into the wifi options, and it seemed to have power_save off indirectly (wifi choosing "kernel default" and kernel default being off). In a different location, it's a lot less severe so possibly an environmental issue or because of the local "mesh" network. 64 bytes from 192.168.68.66: icmp_seq=10 ttl=64 time=3.633 ms 64 bytes from 192.168.68.66: icmp_seq=11 ttl=64 time=4.482 ms 64 bytes from 192.168.68.66: icmp_seq=12 ttl=64 time=3.185 ms 64 bytes from 192.168.68.66: icmp_seq=13 ttl=64 time=105.666 ms 64 bytes from 192.168.68.66: icmp_seq=14 ttl=64 time=3.734 ms 64 bytes from 192.168.68.66: icmp_seq=15 ttl=64 time=16.452 ms 64 bytes from 192.168.68.66: icmp_seq=16 ttl=64 time=16.299 ms 64 bytes from 192.168.68.66: icmp_seq=17 ttl=64 time=4.041 ms

@Sancho link to github issue btw: https://github.com/suyulin/afptool-rs/issues/19

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.

@Sancho this is really cool, and helped to turn that device from paperweight to usable linux OS. Everything seems "ok", though wifi is jittery at best. I also tried building my own image from the github repo, but after completing the build and repack steps, it fails to send to the device. $ sudo ~/Linux_Upgrade_Tool/upgrade_tool uf output/factory/apftool-rs-patched/Armbian-unofficial_26.08.0-trunk_Linknlink-isg-box-se_bookworm_vendor_6.1.115-factorytool.img Loading firmware... Support Type:3528 FW Ver:c.0.00 FW Time:2026-07-16 02:46:46 Loader ver:1.04 Loader Time:2023-12-13 16:28:48 Start to upgrade firmware... Test Device Start Test Device Success Check Chip Start Check Chip Success Get FlashInfo Start Get FlashInfo Success Prepare IDB Start Prepare IDB Success Download IDB Start Download IDB Success Download Firmware Start Download Firmware Fail I'd love to experiment more with it, but no idea how to get past this part.