A big thanks to brunompena for putting together those detailed instructions and pre-compiled images. I was able to use them to upgrade from 15.05 to 19.07.03. Testing it in repeater mode I noticed Wi-Fi throughput was higher than on 15.05 (closer to 15Mbps instead of 10Mbps).
Since it's not directly linked in the above post, the specific instructions I used are linked here.
Does anyone have problems with using ftp with zsun running 18.06 or 19.07?
I have 2 devices running these versions and when i transfer files after 5 minutes the tranfer fails and the zsun reboot itself.
I also have a zsun running 15.05 and ftp is perfectly usable with this version, no reboot at all.
I tried to solve this problem with several solutions in vain.
@brunompena Just followed all upgrade instructions for for OpenWrt 19.07.3 and all went OK
When I try to boot into recovery the zsun led starts flashing very quickly but no Recovery SSID is showing .
Main firmware is accessible ... instructions to reflash the recovery image done 2 times md5sum matches.
But no recovery SSID.
Regards Benny
@0pointnrg Please double check that your device is detecting the SD card events correctly:
logread -f -e sdcard_event
Sat May 16 18:36:39 2020 user.notice sdcard_event: SD Card inserted
Sat May 16 18:36:42 2020 user.notice sdcard_event: SD Card removed
If everything is detected correctly then please try once more the instructions to boot to the Recovery firmware:
ok got timing right to trigger recovery ... I'm on the safe side now 
Thx Bruno
The pre-compiled image for OpenWrt 21.02.0-rc4 (main firmware) and upgrade instructions are now available here.
Your pre-compiled image works flawlessly, thanks! Building an image by patching the imagebuilder doesn't work for me though... I can run the patch and build an image, but after flashing the image, WiFi doesn't turn on (so need to restore from recovery). Has anyone been able to use the imagebuilder yet?
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
IMAGEBUILDER_PATCH="$(pwd)/zsun-resources/zsun-sd100.imagebuilder.ath79[v${IMAGEBUILDER_VERSION}].patch"
IMAGEBUILDER_NAME="openwrt-imagebuilder-${IMAGEBUILDER_VERSION}-ath79-generic.Linux-x86_64"
IMAGEBUILDER_URL="https://downloads.openwrt.org/releases/${IMAGEBUILDER_VERSION}/targets/ath79/generic/${IMAGEBUILDER_NAME}.tar.xz"
IMAGEBUILDER_IMAGE="$(pwd)/${IMAGEBUILDER_NAME}/bin/targets/ath79/generic/openwrt-${IMAGEBUILDER_VERSION}-ath79-generic-zsun_sd100-squashfs-sysupgrade.bin"
wget -qO- "${IMAGEBUILDER_URL}" | tar xJvf -
cd "${IMAGEBUILDER_NAME}"
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 
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?
Regards
Please follow the instructions on the README.md 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)!
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:
Once this is done, you may go ahead and upgrade both main and recovery to the most recent versions.
Hello! I brick the device 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 
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:
mtd4 (kernel) with part2 of the update firmwaremtd2 (rootfs) with part1 of the update firmwareBut instead you did:
mtd3 (rootfs_data) with part2 of the update firmware (this is where you did the mistake)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:
U-Boot images:
Firmware images:
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:
00BE0000 to 00FE0000)Rebooting the device will trigger the new u-boot and start the main firmware which in turn will:
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
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