Bricked Conduit

[Paul Porter]

Hi

I have a MTCDT-H5-210A running FW 1.3.3 It was loaned to someone and when it came back it was exhibiting strange behaviour.
– A Long reset (>5s) would not reset back to the default IP (stuck on 192.168.0.189) and password was not admin.
– The MAC address of eth0 was 00:08:00:4A:0A:8B which could not be registered on Loriot.io as it was registered already even though the user hasn’t signed up for Loriot.

To try and resolve the MAC address issue I followed the instructions here (http://www.multitech.net/developer/forums/topic/permanently-changing-eth0-mac-address/) using the usb-debug connector on the front panel.

After this u-boot no longer hands over to the kernel with the following log:

AT91Bootstrap 3.5.3-r2 (Thu Nov 17 17:15:52 CST 2016)
NAND: ONFI flash detected
NAND: Manufacturer ID: 0x2c Chip ID: 0x32
NAND: Disable On-Die ECC
NAND: Initialize PMECC params, cap: 0x4, sector: 0x200
NAND: Image: Copy 0x80000 bytes from 0x40000 to 0x2ef00000
NAND: Done to load image

U-Boot 2012.10-mtcdt-r6 (Nov 17 2016 – 17:15:52)

CPU: AT91SAM9G25
Crystal frequency: 12 MHz
CPU clock : 400 MHz
Master clock : 133.333 MHz
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
NAND: 256 MiB
In: serial
Out: serial
Err: serial
vendor-id: Multi-Tech Systems
product-id: MTCDT-H5-210A
device-id: 18721609
hw-version: MTCDT-0.0
mac-addr: 00:08:00:4a:0a:8b
Net: macb0
Hit any key to stop autoboot: 0

Loading from nand0, offset 0xa0000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can’t get kernel image!
U-Boot>

Holding the reset button for 5s or longer has no effect.
Before changing the MAC address I saw the following from an SSH session

admin@mtcdt:/# u-boot printenv
ERROR: u_boot.c:main:309: crc does not match on primary env
ERROR: u_boot.c:main:323: crc does not match on redundant env
ERROR: u_boot.c:main:328: both environments are bad: loading DEFAULT_ENV
bootargs=mem=64M console=ttyS0,115200 root=/dev/mtdblock8 ro rootfstype=jffs2
bootcmd=nboot.jffs2 ${loadaddr} 0 ${kernel_addr}; bootm ${loadaddr}
bootdelay=3
baudrate=115200
ethaddr=00:D0:A0:02:0D:E1
ipaddr=192.168.2.1
serverip=192.168.2.2
netmask=255.255.255.0
hostname=AT91SAM9G20
loadaddr=0x21400000
kernel_addr=0x000A0000
admin@mtcdt:/# ifconfig
eth0 Link encap:Ethernet HWaddr 00:08:00:4A:0A:8B
inet addr:192.168.0.189 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2149 errors:0 dropped:0 overruns:0 frame:0
TX packets:951 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:202201 (197.4 KiB) TX bytes:474797 (463.6 KiB)
Interrupt:23 Base address:0xc000

Any idea how I can unbrick this? Can I reflash it through u-boot? If so how?

[Jeff Hatch]

Paul,

You may be able to re-flash from u-boot, but that probably won’t save you. The issue is that the primary env and redundant env u-boot partitions are failing their crc check. This most likely is related to changing the MAC address, though I am not positive about that. What you will probably have to do is restore the u-boot env with a script at the u-boot prompt.

You can file a support portal case at https://support.multitech.com to get a script that you can run at the u-boot prompt to restore the environment.

Jeff

[Brandon Bayer]

Paul,

Instructions and the script for flashing from uboot are here:
http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/

-Brandon

[Brandon Bayer]

But you will need to get the rootfs and bin files for AEP through the portal.

-Brandon

[Alexandros Rapsomanikis]

First of all, it’s a soft brick so no panic.

Secondly, as Brandon and Jeff mentioned, the best way to solve your problem is to create a support ticket at .
The process is quite simple after receiving the response mail. The procedure is actually flashing your device.
You’ll receive a text file with detailed instruction, a script which is essential and saves you a bit of time and of course all the necessary files to do the flashing.

A huge thank you to the guys at the support for providing the files and instruction.

In my case, I didn’t lose the Node-Red configuration/scheme (although I lost a plugin). After flashing, I chose to upgrade to the latest AEP version, just to address some previous issues.

[Author]

Posts