Registered a URL and setup a forum as the IPCam stuff really needed its own site vs my irregular blog posts about IPCam hacking at

Author Topic: Anyone found a serial port on the Maygion MIPS cameras?  (Read 16199 times)

  • **
April 25, 2013, 05:30:13 am
Hi all,

I originally thought the Maygion MIPS cameras were great because you could telnet straight into a BusyBox (Linux) shell, and upload executable files via FTP.  But unfortunately there doesn't appear to be a UART/serial port broken out on the PCB.  I want to get access to the bootloader so I can boot some test kernels over TFTP before I start flashing anything to the firmware.

If anyone else has one of these cameras, do you have any idea where the serial port is?

You can easily identify these cameras by telnetting to them and running 'cat /proc/cpuinfo' and the CPU type will be a MIPS 24K.  The CPU itself is a Ralink RT5350 which includes 2.4GHz wireless-N.

May 20, 2013, 05:26:41 pm

While I was exploring first 5 partitions of flash memory for this cam, I may have corrupted stuff in bootloader or other areas doing some tentative mounts...(though I did not expect just doing mounts could harm).

Now the cam does not boot in standard recovery mode (ethernet and I can not find it anywhere on the network.
Was also hoping for a serial port somewhere, but can't find it.

Would you have any suggestion so that I can restore some life in my cam?

  • **
May 21, 2013, 02:54:37 am
Hi - you probably should have started a new thread since it's a new problem :-P

What were you 'exploring' that might have caused a problem?  Doing tentative mounts shouldn't cause any issues.

Unfortunately unless you can find the serial ports, there's probably no way of accessing the bootloader in order to reflash anything.  I'm not sure whether there are any JTAG ports available either.  Have you tried using the MayGion recovery tool if you have access to a (real) Windows machine?

The bootloader does appear to have some sort of network configuration embedded in it:

Code: [Select]
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off
addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate) ethaddr=$(ethaddr) panic=1
flash_self=run ramargs addip addmisc;bootm $(kernel_addr) $(ramdisk_addr)
load=tftp 8A100000 $(u-boot)
u_b=protect off 1:0-1;era 1:0-1;cp.b 8A100000 BC400000 $(filesize)
loadfs=tftp 8A100000 root.cramfs
u_fs=era bc540000 bc83ffff;cp.b 8A100000 BC540000 $(filesize)
test_tftp=tftp 8A100000 root.cramfs;run test_tftp

So there's a possibility it might try to boot from TFTP or similar if it thinks the firmware is corrupt.  If you use Wireshark, do you see any network traffic from the device when it boots up?

May 21, 2013, 03:36:20 am

Thanks for your answser.
Wireshark does not see any traffic with the cam I'm affraid...
At this stage, only hope would be if someone finds a serial port on the PCB I guess.

BTW, how did you practically access bootloader and other flash sections?

It might just be a hardware issue: Ralink CPU and one motor are heating quite a bit, but close inspection of PCB does not reveal obvious burnouts. Can't tell how hot they become in normal operation.

« Last Edit: May 21, 2013, 11:41:19 am by totototo »

  • **
May 23, 2013, 06:32:37 pm
Yep it sounds like the firmware has become corrupted.  Possibly if you can find JTAG pins you could do a reflash, but looking at the Ralink datasheet the pins are there, but because it's a BGA chip it's near on impossible to figure out where the pins are routed without some kind of X-ray of the board.

I got access to the firmware by copying /dev/mtdblock* to /tmp and then downloading those files via FTP.

BTW if you are looking for a serial port, the kernel boots with the baud rate set to 57600, so I assume the bootloader does the same.

For me the chips never became too hot to touch.

May 27, 2013, 09:44:35 am

Indeed I think the board maybe died, and still found no clue on serial port.

I got access to the firmware by copying /dev/mtdblock* to /tmp and then downloading those files via FTP.
Good idea. Now, once those binary files are on your PC, how did you extract the actual bootloader files, kernel, etc?


  • **
June 01, 2013, 02:10:50 am
/dev/mtdblock0 contained the whole flash chip, while the other mtdblock devices are "partitions" within this.  /dev/mtdblock1 has the bootloader, mtdblock2 and 3 are config areas, mtdblock4 was the kernel and mtdblock5 was romfs, IIRC.

I found a tool called romfsdump which extracted all the files from the romfs image, but there's nothing you don't see when you have a shell on the working device.

The real problem is what happens if you reflash the device with (say) a custom kernel, but then that kernel won't boot?  You've then lost access to the mtdblock devices so there's no way of recovery.  If you leave the bootloader alone then that could be used for recovery (or to boot a test kernel via TFTP instead of flashing it), but then you're back to looking for a serial port...

June 01, 2013, 05:42:21 am
Ok, so you extracted bootloader text from the raw binary then: I thought you could extract all partitions.

Have you tested TFTP boot with say, a copy of original kernel & stuff, but from tftp server?
I guess, as long as the test image injected with TFTP has basic networking & telnetd, then we are not blind without serial port.

  • **
June 02, 2013, 01:39:42 am
Yep, copying mtdblock1 and running "strings" on it reveals what appears to be defaults, however they don't appear to be used.

I would love to be able to get the device to boot over TFTP, but again, this needs access to a serial port to type those commands into the bootloader.  Otherwise it will only boot via flash, as far as I can tell.

August 14, 2013, 11:32:54 am
Can we replace the bootloader with the one from similar hardware? such as the Asus RT-G32.

Architecture: MIPS
Vendor: Asus
Bootloader: U-Boot
System-On-Chip: RT3052
CPU Speed: 320 Mhz
Flash-Chip: MX25L3205D
Flash size: 4 MiB
RAM: 16/32 MiB
Wireless: RT2860
Ethernet: Switch in CPU

CPU, Flashchip as all the same.

Please also note that there are 2 version, one has tftp client and the other one has tftp server(need to have firmware pushed). Maybe ours has tftp server?? Any thoughts?

August 15, 2013, 01:01:42 pm
Source code for RT5350 uboot is here:

If you can access u-boot there is little reason to replace it. You can use uboot commands to update the other flash partitions.

However, if you mess up your u-boot you will probably have to unsolder the flash chip and use an external programmer to recover your board. I'd try to avoid doing that. Of course if the JTAG pins are accessible that is another option, but they aren't accessible on many boards.  They get u-boot into those boards by pre-programming the serial flash chip before soldering it on.

August 16, 2013, 11:40:09 am
We dont have access to U-boot, nor serial nor jtag at the time being.

The reason why I was wondering if we can use some other U-boot was because other U-boot might have tftp recovery on??? then at least we can get tftp working, then flash something onto the ipcam via tftp recovery?!

Any thoughts?