Everything beyond this point may render your device useless. Do not try unless you are willing to open your NAS and learn how to build an JTAG interface.
A word of advice: before doing anything that you haven’t done to a similar device before, check your hartbeat. If it is 60 or over, don’t go further.
In any case, make a copy of your “original” flash image on an usb-stick. Either through one of the original firmwares supporting telnet, an “upgrade” firmware or even the serial console. “cat /dev/mtd0 > /mnt/USB/USB_C/myImake.bin” does the trick.
There is not much to say about the hardware. It is generally a crosssection of the RDC evaluation board. The only differences are the inability of AMIT to distinguish between 0 and 1 (USB0/1 are marked reversed, only eth1 is connected) and a simple hw clock.
The only interesting connector gives you access to the RS232 and JTAG.
GND X o TDI Ser_Tx o o TCK Ser_DTR o o Ser_Rx TDO o o TMS +3V3 o o Ser_RI
For the serial console it is best (and cheapest) to get a mobile phone data cable. Either you buy a serial cable, or some USB (mobilephone data) cables have a 3.3V usb serial converter built in. Google for the pinout. The settings are 38400,8,1,n. http://wiki.openwrt.org/OpenWrtDocs/Customizing/Hardware/Serial_Console
If you are interested in JTAG, use this interface and Software. The Software also works on Windows PE, so you are not forced to install Windows.
JTAG circuit RDC_Loader RedBoot
It looks like there is a new HW 2.0 version (Level One WAP-0007) that is missing the pull-up resistor. Enable JTAG on hardware version 2.0
The RTC is a PCF8563 from Philips/Signetics connected via GPIOs simulating a I²C bus.
General remarks:
The original firmware and the h/w design are products of AMIT. Unfortunately they are not very communicative and interested in supporting open source.
The firmware is very quirky and the toolchain and sources have lots of bugs. Skripts to clean sourcetrees leave trash, so some code never gets cleanly rebuilt. Some parts reference to your host platform, not the toolchain, ...
Some GPL packets are missing “makebin” used to integrate the new kernel and compressed root-filesystem. Some packets have internal errors and can’t be decompressed, others have missing dependencies etc.
The biggest modifications have been done to the boot- and USB section. The bootcode has extensions to check the buttons and branch to the emergency-loader. If this part of the kernel is missing or messed up, the recovery-loader will never be reached. It also is changed to mount the initrd r/w. Another extension to the early setup is a routine to read the h/w clock (a PCF8563 connected via GPIOs used as I²C). Changes to the USB are done for the USB-LEDs and (mainly) hotplugging, controlled by a proprietary binary.
To produce a “compatible” kernel for an upgrade file, only the ext2 driver has to be included in the kernel. The init of the linux system is simplified and is done in /etc/rc.d/rc.bridge. Again most of the essential work is done in a proprietary binary (ed). The binaries reset and led seem to provide the button and LED functions. LED fun can be user triggered by: echo “SHUTDOWN_ON” > /var/run/led.fifo (possible commands: HD_ERR HD_NONE,HD_LT_50p,HD_LT_75p,HD_LT_90p,HD_GT_90p,BA CKUP_ON,BACKUP_OFF,SHUTDOWN_ON,FLASH_ON RET_NORMAL,STATUS_OK).
The configuration is read from flash during startup and placed in /var as ACONF with a working copy. Not yet clear which mechanism is used for flashing back.
unfortunately, this peace of sw doesn’t really help you much, when you have really messed up your box. Even with loading a self compiled “upgrade.img” from the GPL packages, you may have a nonbooting kernel. And since the recovery-loader is started from the kernels bootcode, you are at a dead end. Generally it provides a minimal http service (giving no status info), dhcp service and a tftp service, accepting “unclean” firmware files. (the fw check in the GUI update function is more strict!)
You can either modify the wanted original fw by replacing the branding string (see below) by the one of your original (cca. 4x in the file) and flash it via the recovery-loader. This leaves your branding in tact and enables you to reflash with your original fw whenever you want. Or you use these cross-branding files to get your NAS thinking it is the device of your choice. This changes the branding of your box! Afterwards only fw of the “new” brand are accepted!
Also usefull if you used one of the “unlock” firmwares and need to restore the box to original branding for warranty claims!
CHD2WLANU Conceptronic LLM_RUS001 PE6643 Pearl Queen MGB100 Micronica Queen WAP-0007 LevelOne DDC_RUS001 WAPS-G SMC SMC_RUS001 WMU-6 OvisLink (AirLive) OVS_RUS001 FMW SafeCom SWSAPUR-5 Safeco_RPS001
in the firmware file there are several sections identified. All sections have a 0x50h byte header consisting of following fields:
0000000: 4c4c 4d5f 5255 5330 3031 0000 0000 857e LLM_RUS001.....~ 0000010: 5175 6565 6e00 0000 0000 0000 11e1 6bc7 Queen.........k. 0000020: 00a0 3f00 0060 0000 10c0 3f00 f03f 0000 ..?..`....?..?.. 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 4248 0101 5000 0001 00a0 3f00 0b00 0ab0 BH..P.....?..... 00..0b ASCII branding 0e..0f data checksum 10..1b ASCII product ??? (constant) 20..24 start of affected section 28..2b start address to flash data 2c..2f length of block 30..3f allways zeros 40..47 "BH" rest unknown 48..4b like 20 ??? 4e..4f 0xffff - header checksum rest unknown
This example shows the BIOS header. The dedicated section starts at 0x003fa000 but the BIOS is so tiny, the actual data (length 0x3ff0) only has to be flashed from 0x003fa010. The checksum algo used is:
int csum1( char * A8, int Ac, unsigned short sum )
{
int c;
unsigned short * ptr = (unsigned short *) A8;
for( c = 0; c < (Ac >> 1); c++ )
{
sum = sum + *ptr;
if ( sum < *ptr ) sum++;
ptr++;
}
if ( Ac & 1 )
{
sum += ( *ptr & 255 );
if ( ( sum & 65535 ) < ( *ptr & 255 ) )
sum++;
}
return ( sum & 65535 );
}
Note that the header checksum is calculated with the header checksum field set to zero.
00000010 Linux Kernel 00100010 root fs 003a0010 config 003b0010 filesystem of admin tool 003f0010 System recovery tool 003f8010 MAC-address and branding 003fa010 BIOS sections are preceded by a header like this: 0000000: 0000 0000 FFFF FFFF 3E00 0000 1FEC 4C69 ..............Li 00..07 allways same 08..0d unknown 0e..0f "Li"
The proprietary http binary takes the pages from a seperate uncompressed filesystem (direct access or via proprietary libraries, not mounted). Unfortunately, I didn’t have time to investigate further in this matter. There would be a lot of necessary changes to the html and script code. I think it can’t be too sophisticated (coming from the AMIT company). Maybe it is only some simple fs with modified “magic” (@M!T → AMIT). It has some sort of table, followed by a directory and the data. dir entries are 24byte, filename is 8.3, limited with 0×00. Padding/Filler byte seems to be 0xff.
Try this file to get RedBoot on your NAS.
But beware: This operation overwrites the original BIOS, your MAC, the recovery-loader and parts of the gui filesystem. To return the box to a sane state, you need an image of your former flash! And most probably you will need the serial console to contact RedBoot!
If you mess up the RedBoot, you kill your box (unless JTAG is an option)
In my example the kernel has not been touched, so I only have to restore the BIOS and recovery-loader. The rest is restored by invoking the recovery-loader and flashing a pristine fw when resetting from RedBoot.
RAM: 0x00000000-0x000f0000, 0x00072390-0x000a0000 available MGB100-RB by Schufti 07/08/07 <press Ctrl+C to enter prompt mode> RedBoot> ^C RedBoot> RedBoot> ip_address -l 192.168.22.108 IP: 192.168.22.108, Default server: 0.0.0.0 RedBoot> load -r -v -m tftp -h 192.168.22.55 -b 0x400000 orig_bl.bin | Raw file loaded 0x00400000-0x0040ffff, assumed entry at 0x00400000 RedBoot> fl -s 0x400000 -d 0xffff0000 -l 0x10000 NOR Flash ID = 22a7 [First Sector=3fh,Last Sector=46h] Erase sector........ Programming...