I recently did some trying to boot Armbian on this box and eventually got it not to recognize "Loader" mode using the reset button.

It was working before I eventually flashed an not so compatible u-boot. I knew the risks, sh1t happens

I was trying to boot Armbian from USB by the way, that is why I tried to do this.

 

I discovered that the original firmware is the same as a H96 Max M1 PLUS as we can see from the official firmware file naming: 

rk3528_l001_H96_Max_M1PLUS_6621_64BIT_TAR-20251112.2200.img

 

My question, as anyone had experience with this board?

The idea is to ditch the original firmware and run HA on Armbian (I previously did this with another box using docker).

 

I know the only option now is to "short" the eMMC in order to achieve "Maskrom" mode but there are no obvious pin points on the board.

 

Edited April 6Apr 6 by Sancho
typo

Finally managed to restore the box to stock official Android firmware, everything works as expected. I also tested a firmware for the H96 Max M1, with this one the WiFi is not working, they seem to use a different wifi chip.

Any recommendations on where to start with flashing Armbian on this device?

I got into similar situation and Loader mode is not working now. How did you manage to restore the box? Have you found the correct pins to short? Thank you a lot in advance :)

Hello! @rosic

 

Yes I took a look at the components of the board and eventually managed to find the resistor that interferes with the emmc clock.

Shorting it will put the box in Maskrom mode and enable you to flash the original firmware using the official tutorial from the Linknlink wiki even if you cannot get into Loader mode by pressing the reset button insode the audio jack. I used a metal clamp to short it while I plugged the USB-A to USB-A cable into the 2nd usb port.

 

You can see images here

Official instruction here

Edited April 18Apr 18 by Sancho

Hello, thank you for your response and findings. I eventually also managed to get into Maskrom and reflash it multiple times. I now managed to run a HomeAssistant supervised on it. I used different pins, not a resistor.

I flashed this on it: https://github.com/fensoft/dq08-haos/releases

Important note: update the box to the latest LinknLink image first. It probably updates also kernel. I couldn't boot HomeAssistant without it.

Hey @rosic thank you for sharing, nice find as well.

What image did you use to flash to emmc?

After rebooting my filesystem is read only and I can't update packages.

I used the one from github link shared before - dq08_ha_supervised_3.0.0_r2.img

But wifi, bt and remote controler are not working afterwards. USBs seem to work fine - screenshots from HomeAssistant.

I have 3 of those LinknLink iSG boxes. First one went perfect, second one was flashing there and back, eventually got it working. 3rd one is still giving me troubles 🤷‍♂️😅

Hi guys, I too have one of these paperweights I'd like to use for a real HA instance to have as a backup if my actual server takes a dump. I was hoping for root access as I'm not a novice when it comes to custom bootloader and roms on other devices but this is a whole different monster. Any tips would be appreciated.

After many weeks of research, testing and debugging I managed to put together an Unofficial Armbian Linux build for LinknLink iSG Box SE.

 

• Version: v26.05 Rolling
• Kernel: 6.1.115-vendor-rk35xx
• Flashed and booting from eMMC.
• All hardware working and tested, including Ethernet, WiFi and Bluetooth.
• Source, build and flashing instructions here https://github.com/luisdosreis/linknlink-isg-box-se-armbian

 

If anyone is interested I can share a test image ready to be flashed or you can (and should) build it yourselves.

I plan to add a Home Assistant flavor to the build system in the future.

Edited May 18May 18 by Sancho

@Sancho this is amazing! If you have the test image ready I will be really glad to test it out. I have more than 1 iSG Box SE so I can test it on multiple devices.

@rosic shared it on MEGA, to flash use the instruction provided on my github.

 

 

MEGA links:

• Rom - https://mega.nz/file/10wE1I6D#kMIPehB7qj5D9j6I1hw4aIUhGXMs7ZJsQgUnVFQfNEA
• Checksum - https://mega.nz/file/koh3HSJL#tbUEWwE-cNw1eo9HM4m15Qu0ax9D057HFTgoXd9wvmA

Edited May 26May 26 by Sancho

@Sancho perfect. I will try it out and will inform you later. I have also discovered that the power adaptors packed with the iSG Box are low quality and some of those can't even reach 1,5 A. Which can cause instability issues and failed HA updates, install, armbian crashes, etc.

After a few days of testing I have to say it works great. No issue whatsoever. Stable, usb, eth, wifi, bt works. Great work!

@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.

@Caleb Gilmour are you trying to flash using Rockchip Loader mode or Maskrom mode?

Regarding wifi I will need to to do some performance testing when I have some time, I did not test it widely.

 

Thanks for your feedback!

Edited July 23Jul 23 by Sancho

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.

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
```

 

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.

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

Nice job tracing the afptool issue! @Caleb Gilmour I will try to reproduce and introduce a compatibility mode if I am able to sort it out.

Regarding the wifi, can you try setting power save off and do some testing to see if the pattern remains?
 

iw dev wlan0 set power_save off

 

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

 

@Caleb Gilmour well the antenna inside is pretty weak also... thanks for the feedback!

 

Regarding afptool I will update the repack flow to:

• use the latest upstream afptool-rs on every build;
• let afptool-rs generate and validate the parameter partition itself;
• remove our old custom PARM wrapper, which could cause the parameter partition to be wrapped twice;
• retain only the separate RK3528 compatibility adjustment required by this device. (maybe they could add this as well on their side)

 

This aligns the image generator with the upstream fix and avoids reuse of an outdated cached afptool-rs binary.

 

Note - the issue with this board and why I had to repack afptool-rs:

 

afptool-rs receives the chip family explicitly:

--chip RK3528

 

It then writes a “support type” byte into the RKFW header.

Upstream maps RK3528 to 0x39, which is the normal RK3528 value. This iSG Box SE’s vendor FactoryTool/loader accepts 0x38 instead—the legacy value also associated with RK3566/RK3568 boards.

 

One upstream-friendly solution could be afptool-rs to offer an explicit compatibility choice, for example:

--chip RK3528_LEGACY

or something like:

--chip RK3528 --support-type 0x38

That keeps standard RK3528 output as 0x39, while allowing boards with this vendor-specific legacy requirement to request 0x38 without patching source.

 

Anyway I will probably as soon as I have some time be publishing a new version with these fixes and including a Home Assistant management tool "ha-app" that will allow users to easily install and maintain Home Assistant using docker containers.

Edited August 8Aug 8 by Sancho

Will soon be adding/testing an ha-app that makes managing Home Assistant on the iSG Box SE straightforward, with commands to control services, update active containers, create safe backups, and tune Wi‑Fi power behaviour.

 

Functions:

 

• ha-app status — Shows installed services and their current state. No sudo required.*
• ha-app logs [service] — Shows recent logs for Home Assistant or a selected service. No sudo required.*
• sudo ha-app enable <service> — Enables and starts a service or optional integration.
• sudo ha-app disable <service> — Stops and disables a service.
• sudo ha-app restart <service> — Restarts a service.
• sudo ha-app update — Updates currently running containers without starting disabled services.
• sudo ha-app backup — Creates a safe full-stack backup; briefly stops active services.
• sudo ha-app backup --live — Creates a full-stack backup without stopping services.
• sudo ha-app backup --homeassistant — Creates a safe backup of Home Assistant configuration and data only; Home Assistant is briefly stopped. (Planned)
• sudo ha-app backup --homeassistant --live — Creates a Home Assistant–only backup without stopping Home Assistant. (Planned)
• ha-app wifi-power status — Shows the selected Wi-Fi firmware power policy.
• sudo ha-app wifi-power performance — Disables Wi-Fi firmware deep sleep for lower latency.
• sudo ha-app wifi-power powersave — Enables Wi-Fi firmware deep sleep to reduce power use.

 

* status and logs need sudo if the user is not in the docker group.

Edited August 8Aug 8 by Sancho
missing details

New version available, now with server and desktop versions:
https://github.com/luisdosreis/linknlink-isg-box-se-armbian/releases

 

Check the readme for all the details.

Also if anyone wants to test the Home Assistant helper on your boxes be my guest https://github.com/luisdosreis/armbian-ha-app