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

Community Builds, Projects & Packages
248

Sure, I add it to the weekly building project, you can download here.
If you know how to use docker you can also clone the repo and change config.txt, then build from the source by docker build :stuck_out_tongue_closed_eyes:.

4 Likes
249

I had some problems with previous builds to get usb to work, has anybody tested that yet?

Preferably I'd like to share a samba share from usb. Connect that through a battery pack and bring it in your car on trips and you have a very nice portable film library.

250

Where did you buy the zsun from? was it recently? They seem to have disappeared from aliexpress

251

The original zsun are a bit tough to find, but someone posted earlier about a replica:
https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=eaget+a50&_sacat=0&LH_TitleDesc=0&_osacat=0&_odkw=zsun+wifi+sdreader

Its an Eaget A50, supposedly exactly the same hardware.

252

puteulanus, the imagebuilder gives me an error.
Do I do something wrong?
Steps followed:
I got off "openwrt-imagebuilder-ar71xx-generic.Linux-x86:64.tar.xz" off the link that you put:"https://ci.appveyor.com/project/puteulanus/zsun-builder/build/artifacts".
After extracting it, in a terminal, I execute:
make PROFILE = zsun-sdreader, and I get this error:

....

Configuring ip6tables.
Configuring ppp-mod-pppoe.

Finalizing root filesystem...
/home/normal/Documentos/zsun/18-06/imagebuilder/staging_dir/host/bin/find: '/home/normal/Documentos/zsun/18-06/imagebuilder/staging_dir/target-mips_24kc_musl/root-ar71xx': No such file or directory
/home/normal/Documentos/zsun/18-06/imagebuilder/staging_dir/host/bin/find: '/home/normal/Documentos/zsun/18-06/imagebuilder/staging_dir/target-mips_24kc_musl/root-ar71xx': No such file or directory
Traceback (most recent call last):
  File "/home/normal/Documentos/zsun/18-06/imagebuilder/staging_dir/host/bin/mklibs", line 415, in <module>
    inode = os.stat(prog)[ST_INO]
OSError: [Errno 2] No such file or directory: 'mips-openwrt-linux-musl'
Makefile:156: recipe for target 'prepare_rootfs' failed
make[2]: *** [prepare_rootfs] Error 1
Makefile:108: recipe for target '_call_image' failed
make[1]: *** [_call_image] Error 2
Makefile:192: fallo en las instrucciones para el objetivo 'image'
make: *** [image] Error 2

What am I doing wrong?
I would appreciate your help.

253

I have done the Recovery Mode feature to u-boot. I tested on my device and seems work well.

What's that:

A new feature of u-boot. By Inserting TF card during booting the device can boot to Recovery Mode, with basic wireless support and mtd command, so we can flash the firmware and bring the device back. It's alternatives of u-boot with Ethernet mode and web flash features.

NOTE: It's another new version of u-boot, pls follow the setps below and make sure you have flashed the new u-boot before flash rec series firmwares.

How to use it:

  1. Take the TF card out.
  2. Power up the zsun sdreader, LED start twinkling.
  3. Insert the TF card in 3 seconds.
  4. The LED stop twinkling for a while, then twinkling faster.
  5. After it stop twinkling again, connect the Wi-Fi 'OpenWrt'.
  6. Set the IP address to 192.168.1.2, subnet mask to 255.255.255.0.
  7. Connect the device by command telnet 192.168.1.1.
  8. cd to /tmp, download the firmware.
  9. Flash the firmware by command mtd write firmware.bin system

Follow the setps to flash it:

  1. Download this unlocked LEDE and flash it in luci.
  2. Download new u-boot to /tmp as uboot.bin, cd to /tmp in ssh.
  3. Flash the uboot by command mtd write uboot.bin u-boot
  4. Erase u-boot env by command mtd erase u-boot-env
  5. Download this Recovery Mode init firmware and flash it in luci.

Technical Details

It's mostly like recovery for android, a tiny dual system. When boot start up, if there is no TF card, it will wait for 3s for inserting it. If insert it will boot from recovery partition, otherwise keep doing normal boot. If normal boot faild it will automatically go to recovery mode.

By reduce 2MB from rootfs and change the range of firmware mtd partition, I create a new recovery partition after firmware.

The new mtdparts: 64k(u-boot)ro,64k(u-boot-env)ro,12032k(rootfs),2048k(kernel),2048k(recovery)ro,64k(nvram),64k(art),14080k@0x20000(firmware)

I build a openwrt 15.05 image with only basic wireless support(even dhcp is removed) to reduce the size under 2MB, then put it in.

Cause the recovery partition is out of firmware, it won't be flashed in the feature. I mark it read only also for safe.

The lede-unlocked.bin is a special firmware, with two kernel in 0x9FBE0000 and 0x9FEB0000.
The offical u-boot will boot from 0x9FEB0000
My old u-boot will boot from 0x9FEB0000 and 0x9FDE0000
The new u-boot will boot from 0x9FBE0000 and 0x9FDE0000
So it can be boot by all of those u-boot.

But after flash openwrt-18.06-rec_init.bin the recovery get out of firmware, if you want to get it back there is a lede-unlocked_rec.bin which can flash by luci.

NOTE: After flash the new uboot, you can't flash old firmware directly. The firmwares build from 18.06_rec is for the new u-boot. Firmware and imagebuilder will add to weekly building soon.

2 Likes
254

@golfo I have no idea why it happened but copy all files from /staging_dir/target-mips_24kc_musl/ from SDK to imagebuilder works for me

@Magnets I bought from Tmart but it's sold out now. Buy from superbuy which helps to buy items from Taobao (by pasting the link example to Shopping Agent) may be a way.

@JuggernauT I add usb support to 18.06_rec, it seems works.

root@OpenWrt:~# block info
/dev/mtdblock2: UUID="05105fc9-29341dd5-9c8606df-dc19c9e2" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/mtdblock3: MOUNT="/overlay" TYPE="jffs2"
/dev/mtdblock8: UUID="05105fc9-29341dd5-9c8606df-dc19c9e2" VERSION="4.0" TYPE="squashfs"
/dev/sda1: UUID="3761-6664" LABEL="NO NAME" VERSION="FAT32" TYPE="vfat"
root@OpenWrt:~# mkdir /mnt/card
root@OpenWrt:~# mount /dev/sda1 /mnt/card/
root@OpenWrt:~# df -h /mnt/card/
Filesystem                Size      Used Available Use% Mounted on
/dev/sda1                14.8G      3.4M     14.8G   0% /mnt/card
root@OpenWrt:~#
2 Likes
255

I’d like to thank all of you, who contributed to the success of porting recent OpenWRT releases to the ZSUN Wifi Card Reader. In particular puteulanus for his excellent work; making u-boot upgrading and firmware flashing so easy.
Unfortunately people - people like me :slight_smile: - tend to be lazy: After having successfully upgraded to the initial 18.06.1 as described by puteulanus in Supporting ZSUN Wifi Card Reader (16MB Flash, 64MB RAM, AR9331), I „decided“ to neglect reading any further advises before trying to upgrade to 18.06_rec. Thus I flashed 18.06_rec from 18.06.1 Luci, recognizing afterwards that 18.06_rec needs a new u-boot. Now the device is still reachable via Wifi (telnet, ssh), but there’s no Luci; device is apparently in recovery mode (Supporting ZSUN Wifi Card Reader (16MB Flash, 64MB RAM, AR9331)). Problem is: Since there’s some sort of mismatch between firmware and u-boot - how to proceed in getting back to a full functioning u-boot/firmware setup?

256

I think you need a TTL to get it back :cold_sweat:.

The old uboot will try to boot from 0x9FEB0000 and 0x9FDE0000, which both are in recovery partition. To keep recovery partitions sturdy I mark the recovery partition read-only so you can't flash it in recovery mode. You can only flash system partition but under these circumstances it's just like a stronge partition, unable to affect the boot process.

I will set u-boot partition writeable in new recovery image to avoid this.

For your device, you need use TTL to go to serial console, then use command bootm 9FBE0000 to boot to normal system, flash lede-unlocked_rec.bin in luci, reboot and boot to 9FBE0000 again, use mtd write command to flash the new uboot.


Update: The new reovery is uploaded and replaced the old one. U-boot now can be flashed in recovery.

I have an idea. If remove wireless support and add usb support to the recovery system, by adding a script to do mounting and flashing when the system boot, it can flash a special name file (like firmware.bin) in TF card automatically. Less operability, more user friendly.
I'm not going to implement this, cos I think operability is better. If anyone want to try that can use the source code I used for building recovery image (forked from Emeryth).

2 Likes
257

puteulanus, highly appreciate your support.

I already planned to enable the serial port by soldering tiny wires to the test points.
However, realizing the true challenge of soldering the missing RX connection stopped me from executing this plan. „Thanks“ to the partly bricked device and your advice I start working.
I soldered a wire to the test point for TX - piece of cake :-).
No need to solder a wire to GND, since a hook clip fits perfect - fine.
And then it started to get difficult. Soldering a wire to RX and shortening the missing RX connection was quite awful. It took me a lot of attempts to get the RX connection finally joined with the hook clip. Meanwhile I was pretty sure that I destroyed the PCB totally, since I got an output from the device in the terminal (TX connection OK), but never succeeded in sending key strokes to the device (RX connection faulty). Surprisingly I managed to fix this problem. You just need to be courageous with the soldering iron ;-).
Bottom line: Do not think about shortening the missing RX connection with a soldering iron, if you’ve low temperature solder paste at hand. The use of low temperature solder paste is certainly the better approach.
Now I got the following output on my terminal:

***************************************
*     U-Boot 1.1.4-03f8ecc4-clean     *
*          Build: 2019-06-01          *
***************************************

** Warning: bad env CRC, using default,
   use 'saveenv' to save it in FLASH

  BOARD: ZSUN WiFi SD Card Reader
    SOC: AR9330 rev. 1
    CPU: MIPS 24Kc
    RAM: 64 MB DDR2 16-bit CL3-4-4-10
  FLASH: 16 MB Winbond W25Q128FW
    MAC: 00:03:7F:11:56:48
 CLOCKS: CPU/RAM/AHB/SPI/REF
         400/400/200/ 25/ 25 MHz

Hit any key to stop booting:  1.. 0

Booting image from 0x9FEB0000...
## Error: unsupported image header
Booting image from 0x9FDE0000...

   Image name:    MIPS OpenWrt Linux-3.18.20
   Build date:    2019-06-04 21:00:29 UTC
   Architecture:  MIPS
   OS/image type: Linux Kernel
   Compression:   LZMA
   Data size:     861.3 kB (881921 bytes)
   Load address:  0x80060000
   Entry point:   0x80060000

   Header CRC...  OK!
   Data CRC...    skipped

Uncompressing Kernel... OK!
Starting kernel...

Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Please press Enter to activate this console.

U-boot gives me the following version info:

u-boot> 

Version and build date:
  U-Boot 1.1.4-03f8ecc4-clean, 2019-06-01

Modification by:
  Piotr Dymacz <piotr@dymacz.pl>

bootm command fails:

u-boot> bootm 9FBE0000

Booting image from 0x9FBE0000...
## Error: unsupported image header

And this is what print environment reveals:

u-boot> printenv

bootargs=console=ttyATH0,115200 root=31:02 rootfstype=squashfs noinitrd mtdparts=spi0.0:64k(u-boot)ro,64k(u-boot-env)ro,14080k(rootfs),2048k(kernel),64k(nvram),64k(art),16128k@0x20000(firmware)
bootcmd=bootm 0x9FEB0000 || bootm 0x9FDE0000
bootdelay=1
baudrate=115200
ipaddr=192.168.1.1
serverip=192.168.1.2
autoload=no
hostname=u-boot_zsun-sdreader
bootfile=firmware.bin
loadaddr=0x80800000
ncport=6666
uboot_name=u-boot.bin
uboot_addr=0x9F000000
uboot_size=0x10000
uboot_upg=if ping $serverip; then tftpb $loadaddr $uboot_name && if itest.l $filesize <= $uboot_size; then erase $uboot_addr +$uboot_size && cp.b $loadaddr $uboot_addr $uboot_size && echo DONE! U-Boot upgraded!; else echo ERROR! File is too big!; fi; else echo ERROR! $serverip is not reachable!; fi
fw_addr=0x9FDE0000
fw_upg=if ping $serverip; then tftpb $loadaddr $bootfile && erase $fw_addr +$filesize && cp.b $loadaddr $fw_addr $filesize && echo DONE! Firmware upgraded!; else echo ERROR! $serverip is not reachable!; fi
stdin=serial
stdout=serial
stderr=serial
ethaddr=00:03:7F:11:56:48

Environment size: 1058/32764 bytes

Tried to boot from 0x9FDE0000 instead.
This is the „non-Luci“ release (recovery).
So it seems that there’s no way to boot to a full functional firmware.

258

Hmmm, for init firmware there should be a kernel... Anyway get TTL work then things become easy.
You can flash lede-unlocked_rec.bin in recovery mode by upload it to /tmp and run the command mtd write lede-unlocked_rec.bin system then try bootm 9fbe0000 in u-boot console again.

259

Thanks for your advice.
Writing lede-unlocked_rec.bin to the flash was apparently successful. Got no errors, warnings.
Booting from 9fbe0000 was also successful and LuCi is back :smiley:. Great!
Thank you very much, once again.

1 Like
260

zsun is alive! :fireworks: Thank's so much @puteulanus for sharing your great work! :pray:t3:

261

During testing I lost both kernels (at 0x9FBE0000 and 0x9FEB0000) of OpenWRT 18.06.1 Recovery Mode init firmware.
The device is still responsive, since serial access to u-boot (latest u-boot_rec.bin) is just working fine.
Now I’d like to flash an image using u-boot (cp.b command).
Tested already loady/YMODEM for file transfer. Seems to be OK.
However I’m not sure how to proceed.
Is it feasible/recommended to load lede-unlocked_rec.bin and copy it to flash?
Which target address has to be used in cp.b command? 0x9F020000 or something else?

262

Yes, it is feasible, and should flash to 0x9F020000.

The address can be computed by MTD layout.

We have 256 blocks in this device, each one is 64kb. The Flash address starts from 0x9F000000, one block is 10000 in hex. Due to we have a 64kb u-boot and 64kb u-boot-env, 0x9F020000 is the start address of firmware.

Firmware is using 252 blocks.
Old mtd layout: rootfs(233) + kernel(19)
Newer one: rootfs(220) + kernel(32)
Rec version: rootfs(188) + kernel(32) + recovery(32).

BTW upload a 10M+ file will take more than 20 mins by YMODEM. I recommend flash the recovery image cos it's much smaller. Load it to ram and copy the image to 0x9FDE0000 (DE = 222, uboot 1 + uboot-env 1 + rootfs 188 + kernel 32, rec layout). Then you can boot from it to get WiFi, to upload lede-unlocked_rec.bin faster.

You can get the recovery image by the command in linux or macOS: dd if=openwrt-18.06-rec_init.bin of=recovery.bin bs=64k skip=220 (init bin = 188 + 32 + 32, skip 220 so we get the last 32 which is recovery)

1 Like
263

Many thanks, puteulanus.
Once more an excellent advice.
First of all followed your instruction to extract the (small) recovery image from the „big“ firmware image.
Input file: openwrt-18.06-rec_init.bin
Output file: recovery.bin

dd if=openwrt-18.06-rec_init.bin of=recovery.bin bs=64k skip=220

extracted recovery.bin. Size of recovery.bin: Just 2 MB (2031620 bytes, 0x1F0004).
Started minicom. Connected to serial port. Initiated loady command from u-boot and
triggered YMODEM upload of recovery.bin file from minicom.
Upload finished within 2 to 3 minutes.
Erased flash first and copied recovery.bin to flash.

u-boot> erase 9f020000 +fc0000
Erase FLASH from 0x9F020000 to 0x9FFDFFFF in bank #1
Erasing: #######################################
         #######################################
         #######################################
         #######################################
         #######################################
         #######################################
         ##################

Erased sectors: 252

u-boot> cp.b 80800000 9fde0000 1f0004
Copying to FLASH...     
Writing at address: 0x9FDE0000

Done!

After restart the device booted successfully from recovery image (0x9FDE0000)
and I could easily proceed using Wifi connection.

1 Like
264

What are the proper commands to build this using your Dockerfile?

I tried something a few days ago, but it did not complete successfully.
It ended up looking like some recursive error when trying to find out some path.

265 
git clone -b 18.06_rec https://github.com/puteulanus/zsun-builder
cd zsun-builder
docker build -t zsun .
docker run -d -p 8080:80 zsun

Then open http://127.0.0.1:8080/ in browser to download files.

1 Like
266

getting permission denied on that one, I assume you meant it with a sudo prefix?

267

That is usually because the user permission of docker program, you should have got the note when you install it.

If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:
  sudo usermod -aG docker your-user
Remember that you will have to log out and back in for this to take effect!
WARNING: Adding a user to the "docker" group will grant the ability to run
         containers which can be used to obtain root privileges on the
         docker host.
         Refer to https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
         for more information.

Sudo may works, or run it as root also. For more details check official document.