THIS IS WORK IN PROGRESS – trying to follow the style guide - Original data at the bottom of the page.
Small device with Li-polymer battery rechargeable_battery. The device is marketed as a "wifi NAS" for backup, and for streaming media. It comes in a couple of different flavors (bare, the GauntletNode, or Gauntlet320, which comes with a 320GB 2.5' HDD already installed). The default firmware is based on linux 2.6.21 it appears that "mapower" in taiwan is the original OEM of the device. Patriot seems to have use the hardware as-is, and just "tweaked" the firmware for their purpose.
todo: list more accurate data on the device
|Version/Model||Launch Date||S/N||OpenWrt Version Supported||Model Specific Notes|
|GauntletNode||2012 (?)||-||-||No built-in drive - customer installed. device is picky about drive format|
|GauntletNode 320||2013||-||-||pre-installed 320GB SATA drive (unsure if pre-formatted or not)|
|GauntletNode Aero||2013||-||-||pre-installed 1TB SATA drive (unsure if pre-formatted or not)|
OEM source code is NOT available anywhere (legally anyway). Neither Mediatek (the Soc manufacturer), Mapower nor Patriot has released linux patches, or uboot patches (both GPLv2). That being said, the firmwares are available for download which provide some info about the hardware being used.
|ralink 5350@360MHz||64MiB||8MiB||1T1R wifi||No (used by internal HDD/chipset)||Yes (J1)||Yes? (J6)|
Manufacturer's site: http://patriomemory.com/ follow "drivers and downloads", "accessories", "wifi mobile drives", and finally "GauntletNode 320 - Portable Drive Enclosure", and click "submit". this will lead you to the page to download the manual as well as the "firmware" (see below for more details).
Not available for this device yet. work on getting the hardware tweaked for openwrt in progress.
OpenWRT has a RT5350 set of patches that should work pretty much as-is. The build needs to be setup with just an initramfs though, instead of a full JFFS2 partition. from there, we should be able to upload the new build as a new firmware.
from template - please ignore. warning will be removed once we have a good build and a good way to recover from experimentation…
OEM flash layout is as such
|mtd1||0||0x00030000||Bootloader||uboot with ralink mods|
|mtd2||0x00030000||0x00010000||Config||looks like "nvram" settings for linux|
|0x00030000||0x00001000||Config||0x0 - 0x1000 Uboot nvram settings (based on uboot serial output)|
|0x00032000||0x00002fff||Config||0x2000 - 0x2fff system nvram settings (based on data blocks)|
|mtd3||0x00040000||0x00010000||Factory||calibration data for the wifi chipset (?)|
|mtd4||0x00050000||0x00200000||Recovery||linux kernel 2.6.21 with initramfs missing a lot of code|
|mtd5||0x00250000||0x01200000||Kernel||that partition somehow extends beyond the flash size, it should really be sized 0x005b0000|
it appears however that the partition boundaries and the location of the various bits of data do not quite match the partition layout. for example, mtd2 (the "Config" partition) is really broken down in a couple different sections. that partition seems to have the nvram config starting at 0x00030000, for one "block" (0x00010000 worth of data). but looking closely at the data, it doesn't actually start at the beginning of the partition, there is a whole lot of "ff" values before the string data starts (0x0 to 0x1fff in that partition).
$ xxd -a mtdblock2.dd-nvram
0001fe0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
0001ff0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
0002000: de3f 9461 5765 6249 6e69 743d 3100 486f .?.aWebInit=1.Ho
0002010: 7374 4e61 6d65 3d57 6f72 6b47 726f 7570 stName=WorkGroup
0002020: 004c 6f67 696e 3d61 646d 696e 0050 6173 .Login=admin.Pas
0002030: 7377 6f72 643d 6164 6d69 6e00 4f70 6572 sword=admin.Oper
0002040: 6174 696f 6e4d 6f64 653d 3300 506c 6174 ationMode=3.Plat
0002050: 666f 726d 3d52 5435 3335 3000 7761 6e43 form=RT5350.wanC
0002060: 6f6e 6e65 6374 696f 6e4d 6f64 653d 4448 onnectionMode=DH
0002070: 4350 0077 616e 5f69 7061 6464 723d 3139 CP.wan_ipaddr=19
0002cf0: 5741 4e5f 4d41 435f 4144 4452 3d30 3a41 WAN_MAC_ADDR=0:A
0002d00: 3a44 383a 323a 3734 3a33 340a 0052 4649 :D8:2:74:34..RFI
0002d10: 4354 7970 653d 6666 0054 5850 6174 683d CType=ff.TXPath=
0002d20: 3100 5258 5061 7468 3d31 0000 0000 0000 1.RXPath=1……
0002d30: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0006000: ffff ffff ffff ffff ffff ffff ffff ffff …………….
0006010: ffff ffff ffff ffff ffff ffff ffff ffff …………….
0006020: ffff ffff ffff ffff ffff ffff ffff ffff …………….
0006030: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000ffa0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000ffb0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000ffc0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000ffd0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000ffe0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
000fff0: ffff ffff ffff ffff ffff ffff ffff ffff …………….
system nvram seems to be offset by 0x2000.
the kernel partition seem to be of the wrong size (extending beyond the end of the flash by quite a bit (0x00250000 + 0x01200000 adds up to more than 0x00800000). this suggest that maybe the original setup called for a bigger FLASH chip
|no real intructions are available yet to install OpenWRT on this device. The hope is that we'll be able to do this somehow without loosing the factory/uboot/config|
This section deals with how you install OpenWrt from a device freshly opened.
telnet to the device to backup your flash (dd the various partitions, make a link to /etc_ro/web/ and use wget/curl to download the content of the files. (be sure to backup uboot, factory and config partition from the flash. the kernel partition content is available for download (the bin file from the firmware download).
since the system works completely in RAM, we should be able to reformat the flash to allow for the proper OpenWRT flash partitions.
|got to have a working build first|
The default network configuration is:
|Interface Name||Description||Default configuration|
|br0 (ra0, eth2)||default bridge||10.10.10.254|
info below is from template.
Numbers 0-3 are Ports 1-4 as labeled on the unit, number 4 is the Internet (WAN) on the unit, 5 is the internal connection to the router itself. Don't be fooled: Port 1 on the unit is number 3 when configuring VLANs. vlan0 = eth0.0, vlan1 = eth0.1 and so on.
by pressing the button in the pinhole (opposite side of the case from the battery level button/LED), uboot will boot from "Recovery" instead of "Kernel". Note however that the Recovery kernel seems to have a broken initramfs image (or truncated). bootlog of the recovery kernel complains about commands missing such as "cp" and "rm". It's unclear how to recover from that state. (hopefully, simple using mtd_write to the right partition with a file on the USB drive)
|Recovery||boot from recovery instead of Kernel. Will send a SIGUSR1 when machine is running (need to identify process this is sent to - it is likely just resetting the nvram)|
|Battery Indicator||display battery level using 4 LED - unsure if available from Linux|
|CPU @Frq||MIPS 24K V4.12 @360MHz|
|Flash size:||8192 KiB|
|Flash Chip:||cfeon EN25Q64 64Mbit/8MBytes|
|RAM size:||64 MiB|
|RAM Chip:||ESMT brand 32MiB x2|
|Wireless No1:||SoC-integrated 1T1R rt28xx (?) 2.4GHz 802.11b/g/n|
|Switch:||not sure if present|
|USB:||Yes, SATA gateway attached, not usable for other devices|
Photo of front of the casing
Photo of back of the casing
Note: This will void your warranty!
* Turn the device upside-down * Remove 4 screws securing the bottom of the case. slide the panel and put aside. * If you have a GauntletNode 320 or if you have already installed a HDD, remove the HDD (disconnect SATA/POWER from HDD and set aside) * The plate under the HDD can swivel on the power button side, and is kept down by a latch on the side opposite. Gently pull the tab to release the place. be careful with the SATA cable/connector. * DO NOT ATTEMPT TO REMOVE SATA CABLE (it doesn't appear to be removable) * the battery is attached to the other side of the case using double sided tape. gently prying the battery away from the case. * disconnect battery from main board * once the battery is removed, you should be able to see 2 tabs, one of each side of the case, holding the top side of the device to the "sides" * gently pry those out on both side. take care not to pull the plate until you have all 4 pegs detached. * remove the 4 screw on the board to remove it from the case altogether.
there, you can see the SATA cables (it doesn't appear to be removable), as well as the battery connector. the battery is a 3350mah LiPo. there is the first half of the 64Mbytes of ram on the bottom left of the picture, as well as a row of LEDs to indicate battery charge level when the proper switch is pushed. The flash chip on the top left, 8MiB (cfeon 64mbit – see uboot output for more details)
the red cables have been added to attach a bus-pirate and get at the UART. the two middle pins are RX/TX, and the one away from the other white connector is the ground. those connections are sufficient to be able to reach uboot output. sadly, the nvram setup on flash (mtdblock2?) seems to have an invalid CRC, so it's being ignored, and compiled in default of "boot_delay=0" is used (which makes it hard to recover from a bad flash as-is).
the second white connector (6pins) seems to have at least 4 pins where the traces go directly to the CPU under the shield. this could possibly be JTAG (?)
the switch on the side of the board (by R161) is the recovery switch (starts different kernel in uboot, or sends a signal to some process if already booted) the chip immediately to the right of R161 is the flash chip for the USB chipset (512K CMOS type). the bigger chip above it is a USB to SATA chip. it handle the USB3 to SATA connection (and probably also the RT5350-USB to SATA connection). Some experimentation is needed to find out how the USB cable disables wifi on there (i expect it holds the CPU in reset state as long as something is connected to the USB port). the chip is a ASMEDIA 1053 (?) that only seems to support USB2.0. at the bottom you can see, from left to right, the USB connector (USB3 style connector), the power switch, and the power barrel connector.
on the right side, the switch on the edge is the one that triggers the LED from the other side (battery charge level). top right is the other half of the 64Mbytes of ram. under the shield is the RT5350 SoC. on the left of that there are the two antenna connectors (leads to crappy flat antenna on the case)
I am having trouble identifying the TSOP8 package next to the DRAM chip. not sure what it is (label on there is pretty much all gone).
4 pins are available on the board as a header marked "J1". multimeter probing show that pin1 (closest to the edge of the board) is connected to the GND pin of the flash. PIN1 is therefore GND. Pin4, using the same method, is connected to the VCC pin of the flash.
the UART is on J1. I hooked up a bus pirate to the connector as such (pin 1 being closest to the USB connector/power switch/edge of the board with all the connectors). See this table for cable/color/pinout.
|pin 1||GND||GND (brown)|
|pin 2||RX||MOSI (white)|
|pin 3||TX||MISO (black)|
see http://dangerousprototypes.com/docs/Common_Bus_Pirate_cable_pinouts for more references on the buspirate probes
connect the buspirate to you machine, and to the board (See pins above), and do the following:
(this includes all the settings needed to "see" output from the board)
x. exit(without change)
Set serial port speed: (bps)
10. BRG raw value
Data bits and parity:
1. 8, NONE *default
2. 8, EVEN
3. 8, ODD
4. 9, NONE
1. 1 *default
1. Idle 1 *default
2. Idle 0
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
Raw UART input
Any key to exit
from there, turn on the gauntletnode, and you will see the uboot output in your terminal.
attempting to use the bridge mode, however, i have not been able to get a proper serial console from either the OEM firmware (based on errors i see, i don't believe there is one available) or the OpenWRT (my initial device tree config was not correct – will need to use SPI to recover the flash back to OEM, and reflash new firmware.
→ port.jtag general information about the JTAG port, JTAG cable, etc.
it is likely that J6 is a jtag connector (pin1 through 4 are connected directly to the ralink RT5350, pin 5 to GND (?) and pin 6 is connected to pin 4 on J1, assuming Vcc here)
the last two lines seem to repeat over and over again, with more and more empty lines in between (at first just a line or two, and then dozen, then hundreds of empty lines).
It appears, at this point, that not quite everything is working. that being said, the kernel *DOES* boot, and sends some output to the serial console. (now, with this image, the device is effectively bricked. I need to restore the original firmware with flashrom/spi, and fix that image to have wifi on by default, somehow…)
Original firmware is available for download here (latest as of 2014/01/11)
the zip file contain a single file: PA21_188.8.131.52.bin. that file matches the content of /dev/mtdblock5 once the system has that firmware updated.
boot args are: console=ttyS1,57600n8 root=/dev/ram0
the firmware file (PA*.bin) has a 64 bytes uboot header (including CRC), and a LZMA compressed linux image. You can extract the linux image with
dd if=PA_*.bin of=kernel.lzma bs=64 skip=1. use unlzma to uncompress the kernel image. the initramfs can then be indentified with binwalk, (lzma compressed cpio). binwalk will identify the offset, and you can extract the initramfs by using a combination of
dd if=kernel of=initramfs.cpio.lzma bs=1 skip=<OFFSET_FROM_BINWALK>, unlzma to uncompres the initramfs, and use cpio to extract the content of the initramfs.
From there, you can inspect /etc/rcS and follow the init process on the system
There are two serial ports from the OEM bootlog. i setup the original serial console with only one.
The flash "partitioning" is wrong, and should be corrected in the image, so as not overflowing the flash.
The flash SPI addresses are available in the OEM bootlog.
if kernel doesn't work after flashing, you can recover by booting the recovery kernel, simply by holding the button on the opposite side from the battery indicator while uboot starts. this will cause the kernel in the recovery partition to start, instead of the "kernel" partition. search for "gauntletnode" SSID, connect to it, and assign yourself the IP 10.10.10.100, and telnet to 10.10.10.254. you will get a shell directly. from there, you can use "tftp" to copy a new image (or the original one) to /tmp, and use "mtd_write -w /tmp/openwrt.new.bin mtd5" and flash something else that's valid. Once written, you can reboot normally and see what happens.