Bricked Conduit
Home › Forums › Conduit: AEP Model › Bricked Conduit
- This topic has 4 replies, 4 voices, and was last updated 8 years, 2 months ago by
Alexandros Rapsomanikis.
-
AuthorPosts
-
January 31, 2017 at 8:07 am #16574
Paul Porter
ParticipantHi
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 imageU-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: 0Loading 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 sessionadmin@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:0xc000Any idea how I can unbrick this? Can I reflash it through u-boot? If so how?
January 31, 2017 at 8:30 am #16576Jeff Hatch
KeymasterPaul,
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
February 1, 2017 at 9:56 am #16616Brandon Bayer
BlockedPaul,
Instructions and the script for flashing from uboot are here:
-Brandon
February 1, 2017 at 9:57 am #16617Brandon Bayer
BlockedBut you will need to get the rootfs and bin files for AEP through the portal.
-Brandon
February 3, 2017 at 4:54 am #16651Alexandros Rapsomanikis
ParticipantFirst 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.
-
AuthorPosts
- You must be logged in to reply to this topic.