Sunday, December 15, 2013

Building OpenWRT for MobileLite Wireless

I have always had a fondness for OpenWRT, and I know it suports our MT7620 as a target, so why not give it a shot. I have already cheated a little bit and built a test image with root fs on ramdisk that I loaded directly from the uBoot menu.

Seems that I forgot to write while playing today, so here we have a short summary. After playing with OpenWRT, and making a port for the MLW221, I decided to get ethernet up and running. So after reading a bit of documentation I found the pinout for ethernet.

P5 = Tx-
P6 = Tx+
P7 = Rx-
P8 = Rx+

I found an old router and lifted the pins on the filter, and after a little bit of soldering we have ethernet on our device. This is not a permanent solution, since there is no room for the ethernet connector inside the device. If I have to bring a dongle with me, it might just as well be en USB-ethernet dongle.

But the end result is that we can select to boot from tftp in the uBoot menu, so now it will take a few seconds to transfer the test image, instead of 10 minutes. We are moving forward here.

My alternative ethernet port setup.



Wednesday, December 11, 2013

Fixing the dead device

Time to fix our device again.
We now have a serial terminal and access to uBoot, so this should be doable.

The first thing we want to do is to transfer the stock image to our device. To do this we first need to install ckermit (since we already know that uBoot requires it for file transfer).

First thing we wont to try is booting from memory.
So with our serial cable connected, we press 4 during the uBoot sequence. This puts us in the uBoot bootloader console. We want to load the image from serial, and then boot into the image. Afterwards we want to do a firmware upgrade the normal way, to make sure all settings are correct. So we will have to make sure we have our firmware upgrade memory stick or memory card plugged in.

The procedure for upgrading is roughly something like this, and it might be a good idea to have the power plugged in, I didn't:

In console:
kermit

In kermit:
set line /dev/ttyUSB0 (or whatever your serial port is)
set speed 57600
set serial 8n1
set flow-control none
set file type bin
set carrier-watch off
set prefixing all
set modem none
c (to connect)

Power on the device
Press4
loadb 0x800000
(system waiting for file send)
Press ctrl+\ to
This is going to take a while (roughly 15 min)
bootm 0x800034 (this is our offset to the actual image)

The system boots, and starts the firmware upgrade to the official firmware. After the upgrade the device automatically reboots, and we are back to the standard firmware again.

So now we are back to the development part again. After looking at the kernel booting, I'm not even sure if I want to use this as base. We might be better of just basing it on OpenWRT or something similar. But then again, its fun to learn a bit more about uClinux.

If we really want to play with the device, I guess we will have to get ethernet connection and boot from tftp. The 15min of waiting every time I have to do a recovery starts to annoy me.

Tuesday, December 10, 2013

Device dead after firmware upgrade

In the last post I build a firmware for our cute little device. And as always, I try my luck first, and then fix the errors afterwards. Not totally unexpected, after flashing my new firmware there were little response from the device afterwards. So I guess this is what we call a bricked device. This wasn't totally unexpected since we can see from the source that the firmware update is a part of the uClinux image.

So finally its time for me to actually own the device, and void the warranty. 3 plastic hooks on each side of the case, and a little bit of work and it opens. Inside we find 3 sets of test pads. So this should be possible to fix somehow.

A quick look at the chips inside. We see that the SoC is a MT7620, and its connected to a H5PS5162GFR 512Mb DDR2 SDRAM, and we can also see some other chips, but those should be unimportant to us.

From the MT7620 datasheet we can find that we have two interesting sets of ports.


UART:

TP15 - I don't know where this goes, and it doesn't really matter for us
TP16 - TX
TP17 - RX
TX18 - GNX

Ethernet:
TP5-8
Uncertain on whats needed for a breakout cable here.

I'm uncertain if the JTAG pins are connected or not, and I don't even know if the chip even have the ports in JTAG mode since they share port with the ethernet leds. But then again, I'm pretty certain we won't need JTAG for this.

I pull out a USB to TTL adapter and try my luck. A few guesses, and I get a serial console with the settings 57600-8-N-1.

And this is the output:
============================================
Ralink UBoot Version: 4.1.1.0
--------------------------------------------
ASIC 7620_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
Date:Apr 10 2013  Time:15:50:37
============================================
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, linesz:32 ,total:32768

 ##### The CPU freq = 580 MHZ ####
 estimate memory size =64 Mbytes

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
 0
  
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40
   Image Name:   Linux Kernel Image
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    6274935 Bytes =  6 MB
   Load Address: 80000000
   Entry Point:  8000c310
raspi_read: from:50040 len:5fbf77
   Verifying Checksum ... Bad Data CRC

I guess the firmware image wasn't that good after all. First step is create a semi permanent way to recover when our firmware fails, and afterwards we can start to make our own firmware again. I'm pretty comfortable pressing the pins against the pads while using a serial terminal, but when transferring the firmware I think I'm better of soldering on some pins to the device. Or maybe some short breadboard cables and a little dash of hot glue gun would do the trick. Who knows, maybe i can fit some external connector later on.

Next post will hopefully be on how to fix up the rest, and get back to stock firmware.

If anyone request it I can provide pictures of the components, but its well marked and should be easy to find.

Sunday, December 8, 2013

Building MobileLite Wireless MLW221 from source

If we are going to build the firmware from MobileLite from source, the first requirement is getting the source from the Kingston support pages. This is an self-extracting archive, and can be extracted using RAR, or similar compatible extractions tools. Once we are finished extracting the code, we can have a look at it and try to find out how to attack this project.

The first thing we notice is that it running on a version of uClinux, a simple and well documented embedded Linux version. We know we are going to need a toolchain to be able to cross-compile this, so we have two options. We could do it the hard way, and look at specifications, FCC images etc. to find out the hardware architecture. But instead we will cheat a little bit and just look around in the source. Specifically we look for the definition of CC, the compiler. This tells that they were using the compiler "/opt/buildroot-gcc342/bin/mipsel-linux-uclibc-gcc", which is pretty much all we need to know. Now we know for sure that we are dealing with a MIPS little endian of some sort. And thats all we really need to know. We can also see that the toolchain is quite old buildroot toolchain, since the naming has now changed in buildroot.

Again we are left with two options. We could build a shining new toolchain to use for our mipsel. We also know that gcc342 is a very old version of GCC, and we might bump into quite a lot of annoyances if we try with a toolchain with a 10 year newer GCC version. But mostly because we are lazy, we can be pretty sure this toolchain is available somewhere online. So we do a few quick searches. And quite fast we find a BBS where someone have some issues compiling from source for another kind of device thats using the same toolchain. And a few quick later we have downloaded the source code for that device, and they have been kind enough to include the toolchain together with the source code. All honors to Medion AG.

So now we have everything we need to start working on this. I put the toolchain in the same folder we found earlier, so we don't have to manually change all the Makefiles. You will also need a few build tools, but that should be easy for you to sort out. If we do a quick grep for "/home/" we can see that it refers to quite a lot of absolute paths. It seems like the most of the work is done by a guy named Steven, but it also refers to the homedir of a Winfred. I guess this means we will have to work a little bit to get this up and running. I'm not going to write it all down here, but basically its just fixing include paths.

If you are using dash as default shell for sh (/bin/sh -> /bin/dash) you will got syntax errors when its building some of the packages. I choose to fix this in the makefile of the affected packages, and refer to /bin/bash instead of /bin/sh.

It also complained about missing includes when compiling SSL for the webserver. For now I just changed the Makefile to compile it without SSL. Since we don't really need it right now.

So now we stop at a issue with iconv.

/opt/buildroot-gcc342/bin/mipsel-linux-gcc -c -I. -I. -I.. -I../include -I./../include -I../srclib -I./../srclib -I../lib -g -O2  -DINSTALLDIR=\"/usr/local/bin\" -DLOCALEDIR=\"/usr/local/share/locale\" ./iconv.c
In file included from ./iconv.c:77:
../srclib/gettext.h:26:22: libintl.h: No such file or directory
In file included from ./iconv.c:77:

I guess we have to fix this as well. A quick find shows that missing file is located at "./lib/include/libintl.h", relative to the root dir of the firmware. So I guess we will have to change the Makefiles here. So we just go to the folder "user/libiconv-1.11/src" and edit the Makefile manually, and add " -I$(srcdir)/../../../lib/include" to the include directive.

Next stop:
make[2]: execvp: ./makedevlinks: Permission denied
Strange, lets look a little bit at this one.
If we check the permissions on the file we can see this:
-rw-r-xr-x 1 erik erik 3999 nov.   7  2012 makedevlinks
For some reason the owner (me) doesn't have execute rights on the file, and the same goes for the rcS script. This must be a mistake, so I just add the missing bit. And then it fails again, and the execute bit is unset again. Time to look at the main Makefile. We can see here that it sets the mode to 655 and 675 on all the executable scripts. I really can't understand why, they are not suid or anything. So I just change all of them to be 744. My system, my rules.

Next issue:
cp /home/erik/hack/mobilelite/MLW_SDK_4100/images/erik_uImage /tftpboot
cp: cannot stat ‘/home/erik/hack/mobilelite/MLW_SDK_4100/images/erik_uImage’: No such file or directory
But there is a file called root_uImage, this leads me to think that there is some issue with environment variables. And quite correct, the Makefile at "vendors/Ralink/MT7620" has been changed from "IMAGE = $(IMAGEDIR)/$(USER)_uImage to "IMAGE = $(IMAGEDIR)/root_uImage". I just changed this.

We know its almost finished compiling the firmware and it stops at the image part, so we just issue a "make image". And now it complains that my user doesn't have right to write to the "/tftpboot" folder, and quite correctly so. But then again I don't need the makefile to put the image there anyways, so we just comment this away from the makefile. But I guess this means they have been using some dev kit with ethernet support.

And again, it fails on the root_uImage, I guess this is the reason why they changed the Makefile earler. We just add another line where we copy our $(USER)_uImage to root_uImage. So now the file is like this:
#!/bin/sh
cd CRC_tool
cp '../images/'$USER'_uImage' ../images/root_uImage
cp ../images/root_uImage ./
./CRC_tool root_uImage WMTM-169N
mv ./CRC_root_uImage ../images/
rm -f root_uImage
ver=`grep " VER" ../user/gt_utilities/version.h | cut -d '"' -f 2`
mv ../images/CRC_root_uImage ../images/Kingston_widrive_v$ver.bin
chmod 777 ../images/Kingston_widrive_v$ver.bin
cp ../images/Kingston_widrive_v$ver.bin ../images/mlwfw_v$ver.bin

And finally we have a "working" image. This is where the fun starts. In the next post.

Monday, December 2, 2013

A quick look at MobileLite Wireless

I happened to bump into this funny device from Kingston on sale. A MobileLite Wireless MLW221. It's called a wireless card reader, but I also saw some other functions that interested me.

When traveling I every once in a while take a few pictures, and it wouldn't hurt to be able to take a look at them without bringing a laptop. USB OTG could be an option, but it just seemed a bit to boring so the wireless card reader was the way to go. And I would be able to copy the files from the USB CF card reader to an SD card, as backup.

But the functionality that interested me the most was the hackabillity of the device. On the Kingston webpage I could see that they provides the source for the OS of the device. An uClinux build, and its all there for me to play with. Of course I would have too find the right toolchain, and I expected there to be some binary parts as well. But that wouldn't stop me from adding some functionality.

The WiFi on the device is supposed to be able to act as a bridge, so that gives me quite a lot of possibilities on what I can do with the device network wise.

So now I some different things I want to accomplish with this:
  1. Build the image and flash it to the device
  2. Route all my wireless traffic trough it when traveling (in hotels where you only get access for one device etc.)
  3. Route all traffic over an tunnel (OpenVPN)
  4. Use an USB ethernet dongle, for hotels that only have wired internet access.
  5. Make the device automatically upload the pictures to an online service when I plug inn an special memory card.
 So now I just start on top of the list, and see how far I will get before I loose interest and start another project.

The next post will have some instructions on how to build the source, and requirements.

Sunday, December 1, 2013

What will you find here

I created this blog to have somewhere to write down some of my crazy projects. from experience I know that whenever I start a new project it will most likely never be finished. As soon as I manage to prove that the technical part works I usually loose interest.

My plan now is to post some of the process here, so someone else might be able to learn from my mistakes.