The MAG 254 has two flash chips, one NAND and one NOR (SPI). The firmware is held on the NOR chip (which looks like it can be removed and reprogrammed easily enough, but I think the SoC might have some kind of signature verification baked in, so backup essential,  and directly from the chip, not via the MTD device).

The layout reported by the kernel log looks like this for the NOR chip: –

stm-spi-fsm stm-spi-fsm.0: WARNING: no provision for SPI reseton boot-from-spi system
stm-spi-fsm stm-spi-fsm.0: found device: m25px80, size = 100000 (1MiB) erasesize = 0x00010000 (64KiB)
Creating 5 MTD partitions on "m25px80":
0x000000000000-0x000000050000 : "BootLoader"
0x000000050000-0x000000080000 : "Upgrade Boot"
0x000000080000-0x0000000e0000 : "User's FS"
0x0000000e0000-0x0000000f0000 : "Logo"
0x0000000f0000-0x000000100000 : "BootLoader Enviroment"

and this for the NAND chip: –

ONFI flash detected
ONFI param page 0 valid
NAND device: Manufacturer ID: 0x01, Chip ID: 0xda (AMD S34ML02G1)
Scanning device for bad blocks
5 cmdlinepart partitions found on MTD device stm-nand-flex.1
Creating 5 MTD partitions on "stm-nand-flex.1":
0x000000000000-0x000000400000 : "Kernel"
0x000000400000-0x000007c00000 : "RootFs"
0x000007c00000-0x000008000000 : "Kernel2"
0x000008000000-0x00000f800000 : "RootFs2"
0x00000f800000-0x000010000000 : "Userfs"

The Bootloader partition is where the factory firmware is located. There’s an ELF binary (0x500 bytes long) and a ZLib section immediately after this (or perhaps it’s embedded in the ELF). Deflated, the ZLib section contains text strings suggesting it is U-Boot, but also has strings that relate to the BIOS menu.

This is what I think the boot/check sequence looks like: –

Boot BIOS (blue/white menu). Loads Bootloader from NAND, or from USB etc. Checks the loaded image and transfers control if the signature passes. The private key is initially the default publicly available key pair (stb_secbin.key & stb_pubbin.key).

The Bootloader launches into the update process, and looks for the mag254/imageupdate file. The bootloader checks this file’s signature according to

Bootloader from USB launches directly into update code

# uname -a
 Linux (none) #3 PREEMPT Thu Jun 8 13:10:37 EEST 2017
sh4  unknown
# cat /proc/mtd
 dev:    size   erasesize  name
 mtd0: 00050000 00010000 "BootLoader"
 mtd1: 00030000 00010000 "Upgrade Boot"
 mtd2: 00060000 00010000 "User's FS"
 mtd3: 00010000 00010000 "Logo"
 mtd4: 00010000 00010000 "BootLoader Enviroment"
 mtd5: 00400000 00020000 "Kernel"
 mtd6: 07800000 00020000 "RootFs"
 mtd7: 00400000 00020000 "Kernel2"
 mtd8: 07800000 00020000 "RootFs2"
 mtd9: 00800000 00020000 "Userfs"
 # mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (rw,relatime)
proc on /proc type proc (rw,relatime)
none on /ram type ramfs (rw,relatime)
/dev/mtdblock9 on /mnt/Userfs type jffs2 (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /sys/kernel/config type configfs (rw,relatime)
/dev/root on /dev/.static/dev type jffs2 (rw,relatime)
udev on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
shmfs on /dev/shm type tmpfs (rw,relatime,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

Primary bootloader is possibly from the NOR flash chip, which provides U-Boot to the SoC. This in turn finds a uImage to boot, from the NAND, TFTP, USB, etc. It’s hard to know

From, the following actions are inhibited by the script. This looks kind of like U-Boot being configured to boot the file ‘mag254/Bootstrap’ (which is indeed a uImage containing a Linux Kernel) directly from the USB.

# fw_setenv bootcmd "setenv addusbbs 'setenv bootargs \${bootargs} usbman=on'; usb start; fatload usb 0:1 80000000 mag254/Bootstrap; usb stop; run flashargs addusbbs addmisc; bootm; reset"

MD5 sums of NAND partitions in factory state

42b27b82bc113d59e226cf2e041a38e2  mtd0ro.dump
0139c6c3c75532c50e37d60a395d9831  mtd1ro.dump
594dada82851dc0dab16c2129bd5f5ea  mtd2ro.dump
2d28061b1ed90185b198debdfd3cffd9  mtd3ro.dump
65d7a007e3b541088561aa7198de7b09  mtd4ro.dump
3516290feb6d946cf215f01ec1fc6f6f  mtd5ro.dump
1ba9dfb85a78514bf059019e195475ef  mtd6ro.dump
3516290feb6d946cf215f01ec1fc6f6f  mtd7ro.dump
954e2e5643ed5746c433729a4f5616ab  mtd8ro.dump
081351b0d6e7d470391ee78def58204c  mtd9ro.dump

MD5 sums of NAND partitions after some general use, and after both transitional and operator firmwares have been flashed.

# for i in 0 1 2 3 4 5 6 7 8 9; do dd if=/dev/mtd${i}ro|md5sum; done
42b27b82bc113d59e226cf2e041a38e2  mtd0ro
0139c6c3c75532c50e37d60a395d9831  mtd1ro
6158b2eb96753373c53b5d0b8de32eba  mtd2ro
2d28061b1ed90185b198debdfd3cffd9  mtd3ro
6ecd4e296c85616c9c32518e97a3f5b7  mtd4ro
a1eb0b8d9faff3c4320c04433c66d110  mtd5ro
b033ac4764f05e2eb45cffb5f4070eed  mtd6ro
f7da6276123388db86c9704fad1167b6  mtd7ro
dec33af7e4660e089a91a85f93330a61  mtd8ro
bb6851921b956ec43acf67af39d37a53  mtd9ro



Leave a Reply

Your email address will not be published. Required fields are marked *