Mesh/Meraki sparky

Adrian figured out how to fix the hardware watchdog reset issue here.

Content backed up here in case it goes offline:

Meraki Sparky boards, and constant resetting There's a Mesh internet project at Sudo Room and they've been doing some great work getting a platform up and running. However, like a lot of volunteer projects, they're working with whatever time and equipment they've been donated.

A few months ago they were donated a few hundred Meraki Sparky boards. They're an Atheros AR2317 SoC based device with an integrated 2GHz 802.11bg radio, 10/100 ethernet and.. well, a hardware watchdog that resets the board after five minutes.

Now, annoyingly, this reset occurs inside of Redboot too - which precludes them from being (fully) flashed before the unit reboots. Once the unit was flashed with OpenWRT, the unit still reboots every five minutes.

So, I started down the path of trying to debug this.

What did I know?

Firstly, the AR2317 watchdog doesn't have a way of resetting things itself - instead, all it can do is post an interrupt. The AR7161 and later SoCs do indeed have a way to do a full hardware reset if the watchdog is tickled.

Secondly, redboot has a few tricksy ways to manipulate the hardware:

'x' can examine registers. Since we need them in KSEG1 (unmapped, uncached) then the reset registers (0x11000xxx becomes 0xb1000xxx.) Since its hardware access, we should do them as DWORDS and not bytes. 'mfill' can be used to write to registers.

Thirdly, there's an Atheros specific command - bdshow - which is surprisingly informative:

RedBoot> bdshow name: Meraki Outdoor 1.0 magic: 35333131 cksum: 2a1b rev: 10 major: 1 minor: 0 pciid: 0013 wlan0: yes 00:18:0a:50:7b:ae wlan1: no 00:00:00:00:00:00 enet0: yes 00:18:0a:50:7b:ae enet1: no 00:00:00:00:00:00 uart0: yes sysled: no, gpio 0 factory: no, gpio 0 serclk: internal cpufreq: calculated 184000000 Hz sysfreq: calculated 92000000 Hz memcap: disabled watchdg: disabled (WARNING: for debugging only!)

serialNo: Q2AJYS5XMYZ8 Watchdog Gpio pin: 6 secret number: e2f019a200ee517e30ded15cdbd27ba72f9e30c8

.. hm. Watchdog GPIO pin 6? What's that?

Next, I tried manually manipulating the watchdog registers but nothing actually happened.

Then I wondered - what about manipulating the GPIO registers? Maybe there's a hardware reset circuit hooked up to GPIO 6 that needs to be toggled to keep the board from resetting.

Board: ap61 RAM: 0x80000000-0x82000000, [0x8003ddd0-0x80fe1000] available FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each. == Executing boot script in 2.000 seconds - enter ^C to abort ^C RedBoot> # set direction of gpio6 to out RedBoot> mfill -b 0xb1000098 -l 4 -p 0x00000043 RedBoot> x -b 0xb1000098 B1000098: 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 03 |...C............| B10000A8: FF EF F7 B9 7D DF 5F FF 00 00 00 00 00 00 00 00 |....}._.........|

RedBoot> # pat gpio6 - set it high, then low. RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042 RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002

.. then I manually did this every minute or so.

RedBoot> RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042 RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002 RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042 RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002

.. so, the solution here seems to be to "set gpio6 to be output", then "pat it every 60 seconds."

I hope this helps people bring OpenWRT up on this board finally. There seems to be a few of them out there!