OpenWrt Forum Archive

Topic: Netgear MP101, redux

The content of this topic has been archived on 13 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

The Netgear MP101 MP3 player was brought up before, in the context of somehow unbricking one using OpenWrt.  The response then was that it could not be made to run OpenWrt because the factory firmware runs eCos.

It turns out that the MP101 is based on the ARM9 Marvell Libertas 88W8510H, which is intended for Wi-Fi access point duties, and is indeed used in some of the devices listed in the TableOfHardware <http://wiki.openwrt.org/TableOfHardware>.  Supposedly the device has 8 MB DRAM.  It has an Ethernet port, Wi-Fi, line-level stereo RCA (analog) audio outputs, and a headphone jack.

Needless to say, with Linux/OpenWRT, it could be a lot more useful than it is off the shelf.  (The eCos firmware is functionally limited, buggy, and abandoned by Netgear.)

So my question is: would the fact that it runs eCos out of the box totally preclude it from running Linux/OpenWRT?

Thanks,
Robert

These are going for $10–$20 on eBay.  I'd buy one for someone who could make it run Linux.  It has a bright 4-line × 25-character monochrome LCD display (probably 128×32 pixels).

In case you think nobody's paying attention...

This would be a great project - there are many OpenWRT people whose target system is a music player like the MP101!  However, the first (?) hurdle is a big one: You've got to get at least a minimal version of OpenWRT on the system, so that you have somewhere to start. That step has been figured out for Linksys, Netgear, and other systems, but assuming you have a 88W8510 version of OpenWRT compiled, do you know what it takes to load that system onto the MP101?

Here's hoping that the answer is "Yes"...!

I don't know why I didn't mention it before, but Netgear does provide a ZIP file of source code online <http://kbserver.netgear.com/kb_web_files/n101238.asp>, per eCos's GPL-derived license.  I poked through it and it looks like it's geared for building specifically in a Cygwin environment.

Putting OpenWRT on my Motorola router is the extent of my embedded experience; but provided the Netgear source release is complete, I suppose it would be possible to glean from it how to go about building a MP101-bootable image.

I see that the eCos build dependences are in Debian so maybe I'll play with it a little more and see if I can reproduce the MP101's factory firmware under Linux.

raf wrote:

I don't know why I didn't mention it before, but Netgear does provide a ZIP file of source code online <http://kbserver.netgear.com/kb_web_files/n101238.asp>, per eCos's GPL-derived license.  I poked through it and it looks like it's geared for building specifically in a Cygwin environment.

Putting OpenWRT on my Motorola router is the extent of my embedded experience; but provided the Netgear source release is complete, I suppose it would be possible to glean from it how to go about building a MP101-bootable image.

I see that the eCos build dependences are in Debian so maybe I'll play with it a little more and see if I can reproduce the MP101's factory firmware under Linux.

I've just obtained an MP101, so I had a quick look into this. The bad news is that the Marvell chip has no MMU, so it can't (AFAIK) run OpenWRT. However, that doesn't mean it can't run Linux: the ucLinux patches to the Linux kernel can get it working on a system with no MMU (with all the restrictions that implies, of course). This project (WL-530G) is a Linux distribution for a box that runs on a similar chip. However, the firmwares from that can't just be loaded directly onto the MP101 - they seem to be in a completely different format. The WL-530G firmware seems to have a small header, then a decompressor for the kernel, then the kernel in gzip format. The MP101 file, on the other hand, has a (different) small header, starting with the letters "MRVL", then after the header... it has a lot of data that means nothing to me. Perhaps someone wise around here may be able to provide a clue.

On a more positive note, the board seems to have a space to solder on a JTAG connector with the standard ARM pinout - this could be very useful for trying to get Linux to come up on the box.

I'd be very interested to know whether anyone's interested in getting Linux to work on this box, and especially if anyone has any information that could be useful. (If there are many such people, we should probably take the discussion elsewhere to avoid polluting the OpenWRT forum with information about a box that can't even run it!)

Excellent. I have two units of this MP101 that are sitting on some shelves in the basement. I sure would like it to run OpenWRT and hope you guys can do something about it.

BTW, I poke around this SPH200W firmware source code and there is a pub/microwin/src/ecos directory. Perhaps, you guys can check it out.

(Last edited by mazilo on 18 Apr 2008, 01:37)

psmears wrote:

On a more positive note, the board seems to have a space to solder on a JTAG connector with the standard ARM pinout - this could be very useful for trying to get Linux to come up on the box.

It is a standard JTAG connector. OpenOCD works with this config file:

telnet_port 4444
gdb_port 3333

interface <whatever interface you use>

reset_config trst_only

jtag newtap mp101 cpu -irlen 4 -ircapture 1 -irmask 0x0f

target create 88w8500 arm9tdmi -chain-position mp101.cpu

flash bank cfi 0xffe00000 0x200000 2 2 88w8500

Additionally, current URJtag svn can be used to access the flash:

# jtag

UrJTAG 0.10 #
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

jtag.c:537 main() Warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

Connected to libftdi driver.
jtag> detect
IR length: 4
Chain length: 1
Device Id: 00010101100101000110001111010011 (0x00000000159463D3)
  Manufacturer: Marvell
  Part(0):         MV88W8500
  Stepping:     BAN
  Filename:     /usr/share/urjtag/marvell/88w8500/88w8500-ban
The target is halted in ARM mode.
jtag> detectflash 0xffe00000
Query identification string:
    Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set)
    Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
    Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV
    Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV
    Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV
    Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV
    Typical timeout per single byte/word program: 128 us
    Typical timeout for maximum-size multi-byte program: 0 us
    Typical timeout per individual block erase: 1024 ms
    Typical timeout for full chip erase: 0 ms
    Maximum timeout for byte/word program: 256 us
    Maximum timeout for multi-byte program: 0 us
    Maximum timeout per individual block erase: 16384 ms
    Maximum timeout for chip erase: 0 ms
Device geometry definition:
    Device Size: 2097152 B (2048 KiB, 2 MiB)
    Flash Device Interface Code description: 0x0002 (x8/x16)
    Maximum number of bytes in multi-byte program: 1
    Number of Erase Block Regions within device: 4
    Erase Block Region Information:
        Region 0:
            Erase Block Size: 16384 B (16 KiB)
            Number of Erase Blocks: 1
        Region 1:
            Erase Block Size: 8192 B (8 KiB)
            Number of Erase Blocks: 2
        Region 2:
            Erase Block Size: 32768 B (32 KiB)
            Number of Erase Blocks: 1
        Region 3:
            Erase Block Size: 65536 B (64 KiB)
            Number of Erase Blocks: 31
Primary Vendor-Specific Extended Query:
    Major version number: 1
    Minor version number: 3
    Address Sensitive Unlock: Required
    Process Technology: CS99
    Erase Suspend: Read/write
    Sector Protect: 1 sectors per group
    Sector Temporary Unprotect: Not supported
    Sector Protect/Unprotect Scheme: 29BDS640 mode (Software Command Locking)
    Simultaneous Operation: Not supported
    Burst Mode Type: Supported
    Page Mode Type: Not supported
    ACC (Acceleration) Supply Minimum: 0 mV
    ACC (Acceleration) Supply Maximum: 0 mV
    Top/Bottom Sector Flag: No boot
    Program Suspend: Not supported
jtag> quit
vrnul03074nb:~# openocd
Open On-Chip Debugger 0.2.0-in-development (2009-07-05-20:55) svn:2462M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
jtag_speed: 1
Info : JTAG tap: mp101.cpu tap/device found: 0x159463d3 (mfg: 0x1e9, part: 0x5946, ver: 0x1)
target state: halted
target halted in ARM state due to breakpoint, current mode: Abort
cpsr: 0xa00000d7 pc: 0xffffeb80
Info : accepting 'telnet' connection from 0
Info : Flash Manufacturer/Device: 0x0001 0x0000
flash 'cfi' found at 0xffe00000
successfully checked protect state
#0 : cfi at 0xffe00000, size 0x00200000, buswidth 2, chipwidth 2
    #  0: 0x00000000 (0x4000 16kB) not protected
    #  1: 0x00004000 (0x2000 8kB) not protected
    #  2: 0x00006000 (0x2000 8kB) not protected
    #  3: 0x00008000 (0x8000 32kB) not protected
    #  4: 0x00010000 (0x10000 64kB) not protected
    #  5: 0x00020000 (0x10000 64kB) not protected
    #  6: 0x00030000 (0x10000 64kB) not protected
    #  7: 0x00040000 (0x10000 64kB) not protected
    #  8: 0x00050000 (0x10000 64kB) not protected
    #  9: 0x00060000 (0x10000 64kB) not protected
    # 10: 0x00070000 (0x10000 64kB) not protected
    # 11: 0x00080000 (0x10000 64kB) not protected
    # 12: 0x00090000 (0x10000 64kB) not protected
    # 13: 0x000a0000 (0x10000 64kB) not protected
    # 14: 0x000b0000 (0x10000 64kB) not protected
    # 15: 0x000c0000 (0x10000 64kB) not protected
    # 16: 0x000d0000 (0x10000 64kB) not protected
    # 17: 0x000e0000 (0x10000 64kB) not protected
    # 18: 0x000f0000 (0x10000 64kB) not protected
    # 19: 0x00100000 (0x10000 64kB) not protected
    # 20: 0x00110000 (0x10000 64kB) not protected
    # 21: 0x00120000 (0x10000 64kB) not protected
    # 22: 0x00130000 (0x10000 64kB) not protected
    # 23: 0x00140000 (0x10000 64kB) not protected
    # 24: 0x00150000 (0x10000 64kB) not protected
    # 25: 0x00160000 (0x10000 64kB) not protected
    # 26: 0x00170000 (0x10000 64kB) not protected
    # 27: 0x00180000 (0x10000 64kB) not protected
    # 28: 0x00190000 (0x10000 64kB) not protected
    # 29: 0x001a0000 (0x10000 64kB) not protected
    # 30: 0x001b0000 (0x10000 64kB) not protected
    # 31: 0x001c0000 (0x10000 64kB) not protected
    # 32: 0x001d0000 (0x10000 64kB) not protected
    # 33: 0x001e0000 (0x10000 64kB) not protected
    # 34: 0x001f0000 (0x10000 64kB) not protected

cfi information:

mfr: 0x0001, id:0x0000
qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id: 0x0000, alt_addr: 0x0000
Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0
typ. word write timeout: 128, typ. buf write timeout: 1, typ. block erase timeout: 1024, typ. chip erase timeout: 1
max. word write timeout: 256, max. buf write timeout: 1, max. block erase timeout: 16384, max. chip erase timeout: 1
size: 0x200000, interface desc: 2, max buffer write size: 1

Spansion primary algorithm extend information:
pri: 'PRI', version: 1.3
Silicon Rev.: 0x2, Address Sensitive unlock: 0x0
Erase Suspend: 0x2, Sector Protect: 0x1
VppMin: 00.0, VppMax: 00.0

Unfortunately, the serial port of the CPU is being used to communicate with the Winbond W78LE51P (probably for the IR control). However, there are two jumpers on the board and next to them there's a 4 pin connector. Changing the position of the jumpers will detach the Winbond chip and connect the serial port to the connector.

The boot loader seems to be some proprietary code (Netgear MP101-BLDR).

It bothers me that the MP101 is so close to perfect hardware for an internet radio.  I would like to know if the 88W8500-BAN processor could be replaced with a similar processor that has an MMU so it could run OpenWrt.

I know that semiconductor manufacturers frequently make what is basically the same product but disable certain functions when they are to be sold at a lower prices.  If there is a better processor that is pin-for-pin compatible, it should be worth having the processor replaced so it could run OpenWrt.

The small flash memory could probably also be replaced.  The press release announcing the 88W8500 mentions a USB interface.  Maybe that function is built-in and would work if one were to connect the processor pins...

I understand that router chip makers do not provide any information to the public about their products.  (I can't even find a datasheet for the 88W8500.)  Somehow the public must have acquired quite a bit of information about the 88W8500, because so much open-source work has been done.  Where do they get this information?


If it is not possible to upgrade the 88W8500, the MP101 is pretty much useless.  One might be able to throw out and replace the circuit board or remove the display on the front panel and use it...  I wonder if it might be practical to run OpenWrt on a separate router and redirect the inputs and outputs to the MP101 hardware through the Ethernet port?  (I don't know enough about Linux to know if this is a stupid question.)  If OpenWrt on another router could do that, then it would seem like the MP101 might be able to handle the data transfers using Jeremy's Liberated Libertas firmware at Bitsum.com.

Lloyd

Oh well, so much for this device. Readers here don't seem to be interested in porting OpenWRT to this device. Perhaps, one of the reasons is it only has 8MB RAM.

Mazi,
None of the posts above mention the 8 MB of RAM as the reason OpenWrt will not run.  The main problem appears to be the lack of a MMU in the processor.  There are pads on the MP101 circuit board that appear to be designed for another RAM IC.

I hope that one of the experts who contributed technical information in the postings above will respond to my questions.

The discussion might have continued from here.