MN-100 Development LogBook

My first attempt to investigate MN-100.

First look on PCB: CPU - AMD5106 processor (for some reason without proper marking - MS conspiracy?). Flash memory - Intel 28F160C3BC70. Pleasant surprise! It is 2MBytes flash!! See specification
Connectors - ready to use UART 10-pin connector. Solder place to mount 14-pin JTAG connector (unfortunately my soldiering skills will not be enough to put it in place)

First look on Software: For some reason Micro$oft doesn't offer a an individual files for firmware upgrades for variety of MS labeled broadband network equipment, but rather have a one (12M!) downloadable (MSBNDownload.exe) for all its gears - wireline and wireless - MN-100 up to MN-720. When installed , MSBNDownload extract from itself an individual firmware files and MSBNUpdate.exe update utility. MN100_00.01.11.017_RUNTIME.dlf is a latest firmware for MN-100.

OPEN ISSUE : I have no information about internals of the DLF format ! Mast be resolved ASAP MN-500 firmware is stored in similar format. MN-700 and MN-740 are seen to use different format (two individual files per gear - one for bootloader, one for runtime) .

MSBNUpdate is seen as used uPnP protocol for equipment discovery and update. Further investigation required

First look on bootloader: Connecting rs232 level shifter to the 10-pin UART connector. Usual terminal configuration : 115200 bits per second, 8 data bits, parity - none, 1 stop bit.

Booting immediately unveil VxWorks usual bootloader - normal boot sequence maybe interrupted by pressing any key. When in monitor mode (after interrupt) , menu of low level monitor commands is shown. NOTE: some of the commands maybe extremely dangerous - the fact learned by sad experience (see bellow).

Command "p" prints current boot parameters. Command "c" maybe used to change boot configuration. Sub-menu of "c" change mode offers to set up local IP address and remote TFTP and/or BOOTP servers. This is a usual futures of the "standard" VxWorks bootloader and maybe used for fast image load when new image designed or debugged. (functionality require verification).

As I mention before, trying monitor commands is a dangerous business. Almost immediately I manage to corrupt original image and my MN-100 refuses to load. Bootloader verifies integrity of the image and report it as broken. At this stage , it report setup of the Ethernet port and await for "UI restoration procedure" or something similar (sorry, I didn't store log). Unfortunately, I didn't find how to use MS utilities to correct damaged flash.

Fortunately, I find "x" (xmodem download) command. Usually, it's used to download image into RAM and execute it, but in this bootloader it implemented differently - it maybe used only to program code image in the flash (no other options provided). I had used it with MN100_00.01.11.017_RUNTIME.dlf file and seen sucessful image verification and stored in flash starting from 0x20040000 (see details). Note: useful options for future Linux re-flashing if we manage to get internal structure for DLF files.

Under normal conditions , bootloader unpack runtime image from 0x2004000 into ?? and pass control to the 0x1000.
Interesting note: despite the fact that MN-100 PCB has no wireless capabilities, bootloader monitors offers a number of wireless specific test and configuration commands.

First look on original firmware: Finally, after image repairing, I had been able to proceed with runtime image analysis. It is VxWorks system and may be interrupted by any key. After key interrupt, a usual VxWorks monitor is offered - type "help" for details.
Most interesting commands: "d" is to display memory and "l" to disassemble part of the memory code. Interesting to note that runtime code includes symbol table and "l" sometimes provides a greet level of details. "i" command shows a list of all running tasks.

I had used "d" to get values of CPU registers. I'll use it soon to update register map page.

Command "l" is useful to get original bootloader code in the flash. (note: I have no JTAG support to get it other way and analyse outside). Note two distinctive parts of boot code - one started at 0x20000000, another at 0x20008000.

Spend my valuable time updating register values table. Now it represents a registers values at middle of original firmware execution (steady state)

A few interesting reports from MN-100 debug monitor

-> pc
value = 1081956 = 0x108264 = semQPut + 0xc0
-> i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       67b06c   0 PEND         131408   67afa0       0     0
tLogTask   _logTask       678750   0 PEND         131408   678684  3d0001     0
tShell     _shell         5cde68   1 READY         e3690   5cdb08  1c0001     0
tDhcpcTask _dhcpcMon      5b6844  40 PEND         108264   5b67a0       0     0
tDnsProxy  _dns_proxy_D   5b27c8  40 PEND+T       108264   5b2658  3d0004    82
tDhcpsTask _dhcpsStart    5ae9a0  40 PEND         108264   5ae900       0     0
tHTDM      _httpd         589370  40 PEND         108264   589204       0     0
tHTRQ      _ProcessHttp   5871c4  40 PEND         131408   5870e4       0     0
tNetTask   _netTask       638564  50 READY        108264   6384e4       0     0
reset      _Prd_PreRese   556e9c  99 PEND         108264   556e3c       0     0
nvram      _nv_Task       5bdc74 100 READY         ddc68   5bdbdc       0     0
fpi        _fpi_Task      5bb8d0 100 READY         ddc68   5bb858       0     0
sntpMain   _sntpMain      58ea70 100 DELAY         ddc68   58e9b0       0    65
SSDP_Beacon_BeaconStart   55d1f4 100 DELAY         ddc68   55cf6c       0   584
SSDP_readTa_SsdpReadTas   55a048 100 PEND         108264   559ac4       0     0
value = 0 = 0x0

Runtime code is started at 0x1000
Some of interesting functions:

Symbol	Address	Comments
sysInit	0x1000	sysInit
bsp_ImageVerify	00001088	bsp_ImageVerify.txt
bsp_BootProductCode	00001148	bsp_BootProductCode.txt
bsp_SetBootline	00001270	bsp_SetBootline.txt
usrInit	0x6efc

Check symbol table for something started from "download". Bingo! find download_ProcessImage function. Look like is used to burn flash when a new image downloaded via HTTP. It then calls prd_CheckImage to validate correctness of the Image file.
Deep analysis of prd_CheckImage unveil the internal structure of *.DLF file

*.DLF file structure

Offset	Description	Value from MN*.dlf
0	TF - Type of file	2
4	DL - Data Length (FileLength-80)	0x000b1e6e
8	DC - Data CheckSum (byte) for(i=80; i<=fileLen-1;i++)   DC+ = (byte)file[i];	0x05e2bb5c
0x0c.. 12...	Text Signature	"msfox_wired"
0x4c 76	HC - header checksum: for(i=0;i<0x4b;i++)   HC+ = (byte)header[i];	0x000030ae
0x50... 80...	data file - unknown compression

Decided to check other symbols in vicinity of download_ProcessImage and prd_CheckImage

0x000b8eb4 download_ConfigInit       text
0x000b9004 download_Action           text
0x000b9020 download_SetAction        text
0x000b90a8 download_Mode             text
0x000b90c4 download_SetMode          text
0x000b9134 download_FileName         text
0x000b91c0 download_SetFileName      text
0x000b926c download_ProcessImage     text
0x000b9330 download_ProcessWlanFirmware text
-----
0x000c3094 prd_ResetTask             text
0x000c3138 prd_Reload                text
0x000c3178 Prd_PreResetTask          text
0x000c323c Prd_ResetInit             text
0x000c32e4 prd_FactoryReset          text
0x000c3350 prd_CheckImage            text
0x000c3544 prd_UpdateImage           text
0x000c368c prd_CompareImage          text
0x000c3764 prd_DownloadCfgImg        text
0x000c397c prd_info_SerialNo         text
0x000c39e8 prd_info_HardwareVer      text
0x000c3a54 prd_info_BootCodeVer      text
0x000c3ad4 prd_info_RuntimeCodeVer   text
0x000c3b38 prd_info_RuntimeCodeDate  text
0x000c3b9c prd_info_GetLanMacAddr    text
0x000c3c1c prd_info_GetWanMacAddr    text
=======