Supporting ZSUN Wifi Card Reader (16MB Flash, 64MB RAM, AR9331)

I have re-checked the Image Builder patch and it looks to be OK (all files checksum match).
I also successfully built and tested an image using the instructions I have on the repository page:

IMAGEBUILDER_VERSION="21.02.0-rc4"    # OpenWrt version to build
IMAGEBUILDER_PACKAGES=""              # Test image with no package customization


wget -qO- "${IMAGEBUILDER_URL}" | tar xJvf -

patch -p1 < "${IMAGEBUILDER_PATCH}"
find files/ -type f -exec chmod 0755 {} \;

make image PROFILE="zsun_sd100" FILES="files/" PACKAGES="${IMAGEBUILDER_PACKAGES}" && \
echo -e "\n\nOpenWrt image was built successfully and can be found at:\n  ${IMAGEBUILDER_IMAGE}\n\n"

If I have to guess, you probably forgot to set the executable attribute to the files under files/.

Can you please try the above instructions (copy & paste) and see if that works for you?


I did the copy paste, but still resulted in an image that I could flash but wouldn't work. I then decided to create a new VM to run the imagebuilder in, and then the resulting image suddenly worked. So there must have been something odd going on in my old VM... Anyway, no issues with your patch and/or instructions :slight_smile:


Glad to hear you got it working!

Hi! Great work.

I haven use my Zsun after quite many years. I have right now the version:
LEDE Reboot 17.01-SNAPSHOT r2993+618-b9a408c

Could you let me know a safe way to upgrade to the last version you made?

Please follow the instructions on the found on the main repository page.

If you cannot identify your firmware version and you would still like to attempt the update, then I suggest the variant1 of the update firmware (be sure you want to go forward with it as you may brick your device!).

I have uploaded the patches and pre-compiled images for both main and recovery firmware:

Do not upgrade both at the same time, and only start the upgrade of one of them after you verified you can login to the other (so you can recover in case something goes wrong)!

  • Before upgrading the main firmware, be sure you can login to the recovery firmware.
  • Before upgrading the recovery firmware, but sure you can login to the main firmware.

Hello, I'm on 17.01-SNAPSHOT, r2993+618-b9a408c on kernel version 4.4.103. My md5sum is 27af1351fbae86a9066a38b3b2093216 and want to flash 21.02.0 + recovery. What should I do?

This is the exact same question as @jjrbfi did, just 3 posts above yours...

Based on your firmware version alone I can only guess you are still running the stock u-boot, for which you should use the variant1 of the update firmware (with all disclaimers attached).

The update firmware will make the following changes to your device:

  • Install a new u-boot
  • Install OpenWrt 19.07.0-rc1 as the main firmware
  • Install OpenWrt 18.06.5 as the recovery firmware

Once this is done, you may go ahead and upgrade both main and recovery to the most recent versions.


Hello! I brick the device :slight_smile: I tried variant1 but I used mistakenly the original firmware.

Few years a go I got connected by the pins. Do you think that U-boot is currently installed there to upload at least the original firmware? Do you have copy of that? Thanks!

Really sorry about that :frowning:

Based on my old notes for the MTD layouts:

Original Firmware

dev:    size   erasesize  name
mtd0: 00010000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00e90000 00010000 "rootfs"
mtd3: 00130000 00010000 "uImage"
mtd4: 00010000 00010000 "NVRAM"
mtd5: 00010000 00010000 "ART"

Emeryth Firmware (example for variant1)

dev:    size   erasesize  name
mtd0: 00010000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00e90000 00010000 "rootfs"
mtd3: 00b50000 00010000 "rootfs_data"
mtd4: 00130000 00010000 "kernel"
mtd5: 00010000 00010000 "nvram"
mtd6: 00010000 00010000 "art"
mtd7: 00fc0000 00010000 "firmware"

And assuming I understood you correctly, you wanted to:

  • Flash mtd4 (kernel) with part2 of the update firmware
  • Flash mtd2 (rootfs) with part1 of the update firmware

But instead you did:

  • Flash mtd3 (rootfs_data) with part2 of the update firmware (this is where you did the mistake)
  • Flash mtd2 (rootfs) with part1 of the update firmware (this actually overwritten the mistake from the previous step)

This means your device still has the old kernel but will not be able to boot since the rootfs has been overwritten and in its place is now the kernel of the main firmware (*).
It also means you are still running the same U-Boot since the update firmware was never booted!

I can provide you with the links to the following binaries for you to try recover your device from serial connection:

(*) Side note regarding the Update Firmware (for those interested)

Although there are 3 variants the update firmware, the image itself is actually the same for all variants. The only difference between them is the size of the parts, as they had to be split according to the firmware each variant is targeting.

This means we have one single image that has to be compatible with all kernel locations from the known u-boots (original, puteulanus, puteulanus_rec) and must also be capable of preparing the device to even another u-boot variant:

Update Firmware (temporary layout for installing u-boot and recovery)

  <offset> | <size>   | <name>
  00000000 | 00010000 | u-boot
  00010000 | 00010000 | u-boot-env
  00020000 | 004E0000 | firmware: kernel + rootfs + uninitialized rootfs_data (main firmware)
  00500000 | 006E0000 | update: roofs + initialized rootfs_data (includes the update script, u-boot.bin and recovery.bin files)
  00BE0000 | 00130000 | update: kernel
  00D10000 | 001A0000 | <empty>
  00EB0000 | 00130000 | update: kernel
  00FE0000 | 00010000 | nvram
  00FF0000 | 00010000 | art

At the end of the boot process, the update firmware will call the update script to execute the following actions:

  • Flash the new u-boot
  • Reset/clear the u-boot-env
  • Flash the recovery firmware (overwrites the update kernel's from 00BE0000 to 00FE0000)
  • Reboot

Rebooting the device will trigger the new u-boot and start the main firmware which in turn will:

  • Initialize the rootfs_data (overwrites the update rootfs + rootfs_data from 00500000 to 00BE0000)

By the end of this process, all parts of the update firmware have been completely overwritten by the final images:

Final Layout

  <offset> | <size>   | <name>
  00000000 | 00010000 | u-boot
  00010000 | 00010000 | u-boot-env
  00020000 | 00BC0000 | firmware: kernel + rootfs + rootfs_data
  00BE0000 | 00400000 | recovery: kernel + rootfs + rootfs_data
  00FE0000 | 00010000 | nvram
  00FF0000 | 00010000 | art
1 Like

Hello @brunompena , a few months ago i installed the recovery and the fw. Today I tried to use the device again and when I boot to the recovery partition (with the sd card insert) I can't find any ssid with "Zsun Recovery" when the LEDs are flashing really fast
Already updated the recovery to the latest available on the github and checked the MD5.

The issue you describe seems to be similar to the one reported by @0pointnrg some time ago, so I will quote here the same answer:

The first boot to recovery 19.07.8 should take something like ~45sec, after which the "Zsun Recovery" SSID should be visible.
For completeness, I leave here the md5sum for the u-boot, u-boot-env and recovery (version 19.07.8, immediately after flashing) partitions that are used to boot into recovery:

root@Zsun-SD100:~# md5sum /dev/mtd0
c8437e69c139ad9cbd252ac5d29d46f9  /dev/mtd0
root@Zsun-SD100:~# md5sum /dev/mtd1
ecb99e6ffea7be1e5419350f725da86b  /dev/mtd1
root@Zsun-SD100:~# md5sum /dev/$(cat /proc/mtd | grep recovery | cut -d: -f1)
a5e9ee6d2534a75901205d2c479bc067  /dev/mtd6

Tried the logread, it works!
Checked the md5s, all match.

But still, i insert and remove the card during boot time, when it blinks faster, and still it stays blinking fast for as long as I leave it plugged in, and no wifi ssid found.

Just a note, don't know if it matter but I'm still using version 19.07.3 as the main firmware. I don't want to update until I have the recovery working

If everything matches then it should just work... :confused:

I have uploaded a short video on how to trigger the recovery firmware:

You may also try the alternative u-boot I have just uploaded to GitHub, which should make it easier to boot either the main or recovery firmware.
It uses a different logic to select the firmware to boot, so when you connect your Zsun to the USB it will:

  • Immediately boot the main firmware if the SD Card is inserted.
  • Immediately boot the recovery firmware if the SD Card is ejected.

To flash it follow the below instructions and make sure the md5sum matches:

root@Zsun-SD100:~# md5sum /tmp/zsun-sd100.u-boot.alt.bin
eb1884192d412e8b74c38dc31531d990  /tmp/zsun-sd100.u-boot.alt.bin
root@Zsun-SD100:~# insmod $(find /lib/modules/ -name mtd-rw.ko) i_want_a_brick=1
root@Zsun-SD100:~# mtd write /tmp/zsun-sd100.u-boot.alt.bin u-boot
Unlocking u-boot ...

Writing from /tmp/zsun-sd100.u-boot.alt.bin to u-boot ...
root@Zsun-SD100:~# md5sum /dev/mtd0
eb1884192d412e8b74c38dc31531d990  /dev/mtd0

WARNING: Flashing the u-boot partition is dangerous and may cause you to brick your device - proceed with care!

1 Like

Thank you, the video helped, i was doing the push way later in the boot process.
I didnt try the alternative uboot but seems a good idea, although it requires that there is a sd card permanently inserted

1 Like

Note that it can be a broken one, all it needs to do is trigger the card-inserted switch (which is either mechanical or a very, very basic electric contact).

1 Like

I have a 32MB one inserted all the time (yes - 32 MEGAbytes not giga - one of the few in world I think :slight_smile: )

1 Like

Can someone share the complete ethernet port connection diagram with all the necessary components?

did you see zsun sd100 pics on post linked from top of this thread?

This zsun sd100 video flashes a pic on screen with etherenet connected but doesn't say anything about it.

Ok, I noticed that 1nformatica has a separate video on how to connect the ethernet jack.