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

JuggernauT · October 21, 2018, 10:27am

The benefits far outweigh the disadvantages if you ask me.

JuggernauT · October 21, 2018, 12:35pm

In laymans terms (because that is what I am) if you pressed that button, which means inserted your sd card at the right point during boot) the router settings would be reset.

vk496 · October 21, 2018, 1:58pm

I am not sure about that...

What really do the reset of the device is a hook executed when the device enter in failsafe mode:

github.com

gdm85/openwrt/blob/0f8c1d58e307d67b5c80f5cc72d732281070f562/target/linux/ar71xx/base-files/lib/preinit/50_failsafe_wipe

#!/bin/sh

failsafe_wipe() {
      echo "Doing a factory reset."
      mount_root
      firstboot -y
      sleep 10
      reboot -f
}
  
boot_hook_add failsafe failsafe_wipe

What you posted, is triggered by the microSD insert event (GPIO 22, ZSUN_SDREADER_GPIO_SW_SD), which execute BTN_1:

github.com

gdm85/openwrt/blob/0f8c1d58e307d67b5c80f5cc72d732281070f562/target/linux/ar71xx/files/arch/mips/ath79/mach-zsun-sdreader.c#L51


      
          		.name		= "zsunsdreader:green:system",
          		.gpio		= ZSUN_SDREADER_GPIO_LED_SYSTEM,
          		.active_low	= 0,
          	}
          };
          
          static struct gpio_keys_button zsun_sdreader_gpio_keys[] __initdata = {
          	{
          		.desc           = "SD Card insert switch",
          		.type           = EV_KEY,
          		.code           = BTN_1,
          		.debounce_interval = ZSUN_SDREADER_KEYS_DEBOUNCE_INTERVAL,
          		.gpio           = ZSUN_SDREADER_GPIO_SW_SD,
          		.active_low	= 1,
          	}
          };
          
          
          static void __init zsun_sdreader_common_setup(void)
          {
          	u8 *art = (u8 *) KSEG1ADDR(0x1fff0000);

github.com

Emeryth/openwrt-zsun/blob/6aef476cb55779c270c31bf6f55cf13bdac56578/target/linux/ar71xx/base-files/etc/rc.button/BTN_1

#!/bin/sh

logger Resetting the SD card reader
echo "0" > /sys/class/gpio/gpio18/value
echo "1" > /sys/class/gpio/gpio18/value

But what really imply enabling & disabling the GPIO 18, is what I don't understand (and have yet device to try)

hmmm.... Maybe rebooting to enter in failsafe mode? I'm not 100% sure...

Anyone could check it? Would be helpful

maurer · October 21, 2018, 7:16pm

the device needs to be booted to be able to trigger factory defaults (BTN_1)
there is no way currently to enter failsafe mode in u-boot

vk496 · October 21, 2018, 7:19pm

Are you sure that the SPI Flash is wiped from a simple GPIO 18?

Seems not be possible. I think GPIO 18 must do something different...

BR

vk496 · October 22, 2018, 2:44pm

Hello,

I've build a bootloader image and OpenWrt firmware based on the last stagging source code (Tue Oct 16 14:16:48 2018 +0200)

Warning: Nothing is tested yet. Recommended for experts

The OpenWrt image not follow the original MTD partitions layout. Because of that, the original bootloader will not boot this OpenWrt image because the offset is in a differente space.

The layout that is used in u-boot & OpenWrt is: 64k(u-boot),64k(u-boot-env),16128k(firmware),64k(NVRAM),64k(ART)

U-boot source code used for the image: https://github.com/vk496/u-boot_mod/tree/zsun_support
OpenWrt source code for the firmware build: https://github.com/vk496/openwrt/tree/zsun
Images ready to flash: https://drive.google.com/drive/folders/1vZOLcr-EhBR8kpC1UM956h7Sj_np4h89

If you don't have serial access to the device, you must make sure that the new bootloader will boot the new kernel. You must flash both (OpenWrt and bootloader) before reboot the device. Probably you will need something like mtd-rw to flash the bootloader from OpenWrt.

This OpenWrt image comes with a special wifi-enabler. You must have a FAT32 microSD inserted when booting with a file called openwrt_wireless (empty is also ok). If at boottime this file is detected, the wifi will be activated and the special file will be deleted.

factory defaults should also work.

Emeryth · October 22, 2018, 6:55pm

GPIO 18 is used to restart the SD card reader chip (not the SoC or flash memory), it has to be reset every time you insert a card or else it doesn't work.
That's why it is triggered by the card insert "button". The use of that button to enter failsafe is unrelated to the use of GPIO 18.

maurer · October 22, 2018, 6:55pm

considering you can barely find these devices for 15$ (discontinued product) I would say it's risky business testing the bootloader
...
LE - I just noticed you don't include the packages for fat32 in the default image - how will it be able to mount the uSD ?
...
after taking acloser look inside the image bin i've noticed you DID include the fat32 support in your build ! well done !

macromorgan · October 23, 2018, 7:42pm

If you're going to go, go big. As long as we're tinkering with uBoot is there a way to add an SD card read function in there as a failsafe, even if it means expanding uBoot to 128k and moving the uboot-env partition?

I don't have the soldering skills to get a serial port on mine, but I do have a pomona clip and a raspberry pi...

vk496 · October 23, 2018, 9:24pm

Failsafe (and automatically reset OpenWrt) should work if you insert SD card when booting.

vk496 · October 23, 2018, 9:25pm

Anyone could please upload original mtd0 and mtd1 partitions? (u-boot and u-boot-env)

I don't have the device yet.

Thanks in advice

vk496 · October 24, 2018, 8:16am

Screenshot_20181024-092419

Hope I can get one zsun to finalize the OpenWrt support...

maurer · October 24, 2018, 4:24pm

it's 15$ on ebay

vk496 · October 24, 2018, 4:26pm

Is discontinued. Will try with clones of zsun (seems identical)

maurer · October 24, 2018, 4:31pm

that was exactly what i would recommend - the eaget a50

macromorgan · October 24, 2018, 6:01pm

I’ll get the files for you Friday if no one else does by then. I’m out of town for work at the moment.

maurer · October 25, 2018, 6:18am

here you go https://gofile.io/?c=JeF1ZV

Camicia · October 25, 2018, 7:30am

Interesting developments. If the u-boot does not work to recover the device you will probably have to take out the chip to use JTAG. I saw this one before: https://github.com/pepe2k/u-boot_mod/pull/105 - Since the guy never replied I wonder if he ended up bricking the device.

At the moment you can buy them for $10 shipped from China. Very nice devices, I am not sure why they discontinued them.
They should at least have a new version that support 5Ghz and latest kernel.

maurer · October 25, 2018, 7:39am

where can you buy it at 10$ ?

Camicia · October 25, 2018, 8:06am

@maurer If you google it, it is the first result in the shopping section...

@vk496 A lot of enthusiasm considering that you do not have a device yet
I was looking at: arget/linux/ath79/base-files/lib/preinit/79_enable_wifi

It looks like that you turn on the wifi when the file is on disk. Did you implement this to go around this message ?

How is the decision of turning on an unprotected wifi with a file on SD any different than just plugging in the device?
I though that the problem is the risk of having a unprotected wifi open to the world and this does not seem to fix it. What do you think @pepe2k ?

If you could read the the WIFI configuration (name, password etc), would it solve the concerns? What do you guys think?

In general, should Openwrt have a clear policy?
Could the policy be something like this?

If the device supports a wired connection, the WIFI is off by default
and the wired connection needs to be used first. 

If the router does not have a wired connection but supports media
devices like USB, SD, etc, a file with WIFI credentials needs to be
used [JSON would be nice]. When the file is detected for the first
time after first boot, the WIFI is set up according to what is in the
file and turned on. It could even give a way to set up the password
and leave the WIFI unencrypted. 

For the rest of the devices, a "best effort" strategy should be used.
But if the wifi is the only way to access the device (even if it may 
support others but there is not a working driver yet), an open 
"Openwrt" wifi on first boot is tolerated.

There are other ways to make the device more secure on first boot but they make it less easy to use and probably require some extra development work.

From my point of view saying "We cannot accept code for devices that turn on an unprotected wifi by default" is a little dumb considering that SSH and HTTP are accessible only on the WIFI on some devices. This ends up being "We cannot support these devices".

This discussion should probably have its own thread.

EDIT: policy enhancements