Home/Support/Support Forum/Original U-Boot loader critical bug or New Connect ME 9210 Module HW fault
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Original U-Boot loader critical bug or New Connect ME 9210 Module HW fault

0 votes
Hi,
link for similar problem: http://forums.digi.com/support/forum/viewthread_thread,15855#41664

I have Digi Connect Me Linux JSK.
After first insertion of module in development board JTAG connector (0.8 mm small SMD and fragile) broken. I am without JTAG.

I started first time to play with Digi ESP. Sw instalation and compilation of new kernel and rootfs passed so easy. But upgrade with tftp boot failed.

U-Boot 1.1.6 (Jan 5 2011 - 16:09:48 - GCC 4.3.2) DUB-RevF6
for Digi Connect ME 9210 on Development Board

I spent two days discovering problem. I checked files, CRC in images, 3 times made new compilations, 20 times uploaded image. After corruption of my kernel in flash I uploaded original kernel image from ESP SW installation. Every time in console received message:

CME9210 # update linux tftp
TFTP from server 192.168.42.1; our IP address is 192.168.42.30
Filename 'uImage-cme9210js'.
Load address: 0x200000
...
Verifying: complete
Update successful
CME9210 # reboot
...
## Booting image at 00200000 ...
Image Name: Linux-2.6.28.10-del-5.2-RevB
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1084072 Bytes = 1 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... Bad Data CRC
command bootm 0x200000 failed


I started forensic activities:
a) checked with hex editor kernel image
b) made hex dump of tftp transfer with Wireshark
c) ordered printout from boot loader in console window
(CME9210 # md 0x200000 0x10000)

Results:
-Comparison of tftp hex dump and kernel image in hex editor confirmed successful image transfer.
-Console boot loader printout shown corrupted data in memory.
Comparison with tftp packets shown that from every tftp paked last 150 Bytes replaced with zeroes.

Kernel image in Connect ME 9210 module memory after tftp boot is corrupted. There is in almost 800 intervals about 1250 Bytes of correct data followed with 150 Bytes of zeroes. Corupted area looks like:

002004b0: ea000099 6901b110 fffffff0 eaffff79 .......i....y...
002004c0: ea000036 ea000094 56050000 ff0f0000 6..........V....
002004d0: eaffff74 ea000031 ea00008a 00020000 t...1...........
002004e0: 000f0000 eaffff6f ea00002c ea00008a ....o...,.......
002004f0: 00050000 2680b5e6 00000000 00000000 .......&........
00200500: 00000000 00000000 00000000 00000000 ................
00200510: 00000000 00000000 00000000 00000000 ................
00200520: 00000000 00000000 00000000 00000000 ................
00200530: 00000000 00000000 00000000 00000000 ................
00200540: 00000000 00000000 00000000 00000000 ................
00200550: 00000000 00000000 00000000 00000000 ................
00200560: 00000000 00000000 00000000 00000000 ................
00200570: 00000000 00000000 00000000 00000000 ................
00200580: 00000000 00000000 00000000 00000000 ................
00200590: 00000000 e3a00000 ee070f10 e1a0f00e ................
002005a0: ee110f10 e3c0000d ee010f10 e3a00000 ................
002005b0: ee070f17 ee080f17 e1a0f00e ee110f10 ................


Kernel images on PC is good, tftp transfer is correct, bootloader is original factory loaded in module.

Module hardware or boot loader destroyed at the end of each transfered packet by tftp about 150 Bytes.
asked Mar 31, 2013 in Linux by bgeci New to the Community (1 point)
recategorized Sep 20, 2013 by tuxembb

Please log in or register to answer this question.

1 Answer

0 votes
which JTAG pin is broken?

there have been some issues reported due to TFTP servers working incorrectly. could you retry with this Windows TFTP server:

http://ftp1.digi.com/support/patches/i.MX51/TFTP_Server.zip

If you are 100% sure the TFTP transfer is correct, I'd say the images in RAM got defect. Since this was never reported by anyone else, I doubt for U-Boot bug, but more you have a defect RAM chip on your module.

Please try the U-Boot build in RAM test methods "mtest", but skip the area in which U-Boot is in RAM.

Is the TFTP transfer already corrupt after direct TFTP to RAM, or only after you update to flash and reboot=re-read from flash to RAM? Maybe a flash failure?
answered May 2, 2013 by User143 Community Contributor (132 points)
...