Introduction

As with many embedded devices, it's possible to get your MG-350HD's internal firmware into a state whereby the unit won't work and can't be reflashed in the normal way. This process is usually called "bricking" and your media player is now "bricked" or a "brick". The reverse process is called "debricking" or "unbricking" and after performing it your MG-350HD is "unbricked". As the manufacturers of embedded devices make the debricking process rather difficult, and dependent on secret knowledge and undocumented connectors, stronger terms are used at times.

This serial approach to recovering your MG-350HD will only work if the bootloader at the start of the flash is intact. If your unit died due to reflashing with firmware with a wrong kernel or disk image, then the loader should be OK. If it died due to loss of power during an erase/flash cycle, then you're probably out of luck. If your blue light flashes on power on, and never stops flashing, then you're probably OK with the approach here. Otherwise, you need to contact your MG-350HD vendor to get it fixed.

To use the MG-350HD's serial port you will need a special cable with a voltage shifter (the MG-350HD's serial is 3.3V versus 12V for a PC's serial) but the cables are only a few dollars and you can even make your own.

The instructions for connecting the cable are here on the hardware page.

If you get really keen, you can even install your own permanent console port

Firing it up

If you then connect the cable to a PC and fire up Hyperterminal (or similar) with the settings on 38400 for bit rate, no parity, one stop bit and xon/off handshaking (38400-8-N-1) you should see the serial loader messages as you power on the MG-350HD. If you don't, try swaping RX and TX and check your settings.

Here is roughly what you should see. Your output may look different if you have a different flash chip, and you may well see an error if your Linux kernel didn't decompress correctly due to it being corrupt.

TANGO10 boot loader v0.12.15 for generic2/unnamed board 
(C) Copyright 2002-2005 Sigma Designs, Inc 

NOTE: this boot loader is designed to boot kernels made with the 
      2.4.xx releases of the Sigma Designs ARMutils package 

Built at Aug 16 2006 10:52:05 
Loaded to 0x90060000 
Found boot configuration 
Booted from parallel flash. 
CPU freq.: 166 MHz 
DRAM size is 64MB (64MB/0MB) 
DRAM0 Params (0xe63001f8/0x00092433) 
AMD: JEDEC Device ID is 0xE0. Assuming broken CFI table. 
Swapping erase regions for broken CFI table. 
0030.0030 mfr 00ec id 00e0 Top bootsector 
Flash 0 at 0x46000000 
  ID : AMD/Fujitsu Standard 
  Size : 8192 KB 
  Buffer Size : 0 
  Regions : 2 
    0 : 0x00000000 - 0x00010000 * 127 
    1 : 0x007f0000 - 0x00002000 *  8 
bootconfig = 9008C000 
bootconfig_load: last = 1 
old_config_size = 00003148, new_config_size = 00003148 


  Current MAC Address : (xx:xx:xx:xx:xx:xx) 


This uses the micom with power control[2a000000], version[3] 
led : 0x40000000, data 0x40000000

Login

To get access to the serial loader's menus, you have to send a character on the serial interface to the MG-350HD at the right time.

Since the time window is very short, the easiest way is to press and hold the space key on the PC (in Hyperterminal) as you power up the MG-350HD. You will get a sign-on message which ends with "This version of fips..." and the MG-350HD is waiting for a pasword to be entered. Note there is no prompt to enter this string - the MG-350HD will just echo your typing until you type the magic string.

The correct password is:

MediaGate.

Note the capitalization and the period at the end.

Reflashing: just the romfs

When to do this: You've bricked your system by applying a .upgrade file that did not contain the boot image, and something went wrong; perhaps you lost power partway through, perhaps the .upgrade image you applied was just plain broken.

Preparation

1. Prepare correct working upgrade file without bootloader.

2. Remove the first 28 bytes from upgrade file. One way to do this is

dd if=input.upgrade of=output bs=28 skip=1

Downloading: via the serial cable

1. Uuencode the file created at preparation.

uuencode output output > output.uue

2. Download uuecoded file (output.uue) via serial cable. After issuing the command, start the file transfer from your PC to MG-350HD using your favourite communication program on the PC-side (e.g. Hyperterminal). No transfer protocol is required -- just dump the uuencoded file into the serial port.

download serial romfs

It would take 3 hours to download the file at 38400bps.

Possible improvements on this method (untested)

1. reconfiguring the serial port on the MG-350HD to run at a higher rate; the bootloader supports setting the UART to run at up to 115200bps, but that might make things a little flaky on the transfer. Presumably because there's no hardware flow control lines on the serial header, it uses software flow control (XON/XOFF, aka Ctrl-S/Ctrl-Q). If this worked, it would cut the serial download time by a factor of 3
2. using the inbuild 'gz' option to transfer a gzipped romfs image. Since it uses a cramfs and a gzipped linux kernel, the space savings are at most 2% of the file size; this probably isn't worth the bother.

Downloading: via the network

First you have to configure the network settings. It appears to be the case that the unit can't handle anything more fancy than thinking about one other system, so the gateway, server, and DNS server all have to be the same IP address. For our purposes though, that's not a problem.

Configure your TFTP server

Install and configure a TFTP server. This is left as an exercise for the reader, since there are many different ones, and many ways of setting them up. Regardless, you'll need to have the romfs.bin file (called exactly that, which is created at preparation) world-readable in the directory that tftpd is looking in. You'll also need to know the IP address of your TFTP server, and it needs to be on the same network as the MG-350HD.

Configure the network

First you have to set up the network configuration, otherwise the unit won't be able to talk to your server. You can probably do this with DHCP (previous text here was in error, and a result of a faulty network cable):

boot> net dhcp

If you want to configure IP addresses manually, feel free to do so:

boot> config net

  Protocol    : (0) None (1) Static IP (2) BOOTP (3) DHCP : (3) 1

  MAC Address : (xx:xx:xx:xx:xx:xx)

  IP Address  : (192.168.0.1) 192.168.1.2

  Netmask     : (255.255.255.0)

  Gateway     : (192.168.0.1) 192.168.1.1

  DNS         : (168.126.63.1) 192.168.1.1

  Server      : (192.168.0.1) 192.168.1.1

boot>

Obviously, use IP addresses appropriate for your network here

Download the romfs image

boot> download net romfs

Getting (romfs.bin)...

Write the downloaded image to flash

This step is simple.

flash romfs

WARNING!!! Do not power-off the MG-350HD during this operation!

After the reflash is complete, you can power cycle the MG-350HD.

Reflashing: everything, including the bootloader (can't be done)

There is no known way to do this yet. That's why it's good to never apply a .upgrade file with a boot.img in it, just in case something goes wrong. If you have a unit that has a corrupted bootloader, you pretty much have a doorstop.

If someone with the appropriate JTAG knowledge really gets stuck into it, it might be possible to reprogram the bootloader as well. This is powerfully unlikely at this point, though.

There is an interesting e-mail and the guy said no JTAG debugging option on EM8620L. The difference between EM8620L and EM8621L is EM8621L doesn't have macro-vision. See Sigma designs document.

Bootloader command set

The bootloader appears to support the following commands (type 'help' at the prompt to see the list):

Random speculation

• it would be nice if the bootloader could be persuaded to try a network boot by default, and fall back to flash later. The line at boot that says "Found boot configuration" suggests that this might be possible without having to hack the bootloader code too much.
  • the boot message states that it loads to 0x90060000 and later that the bootconfig is at 0x9008c000 -- this is beyond the end of the boot image, and so probably isn't touched by a reflash. It's 3148 bytes long, unless that's hex, in which case it's 12616 bytes long. That's quite a lot of space for config information. It's possible that this is the saved config data from the "settings" screen, but in that case why isn't it in the flash range (0x46000000 - 0x46800000)?
• There is support in the bootloader for booting from other devices too: attached IDE devices, or an attached CDROM (presumably attached via the internal IDE interface?) Tests of this using romfs.bin and linux.bin on an NTFS primary partition on a CF card failed.
  • perhaps try: single partition, FAT32 only?

This page has been viewed times.