Hi,
I am getting so frustrated.
I have been running my esata modified plug very successfully on a 8GB Transcend class 6 SDHC card although several times I have had to reformat and rebuild the RFS due to errors induced in the card due to mechanical disconnects and power offs, and even finger trouble on my part.
I run the plug from a kernel and RFS on the SDHC card, using the Esata drive as a data store only.
I bought two Kingston 8GB class 6 HDSC cards so I could do a rotating 3 card backup. I prepared the two new cards EXACTLY as the Transcend card. I thought that this would then save time if I corrupted my working card, I could just swap to a new card and re-clone the failing card at a more convenient time.
Was I ever wrong!... I have spent (wasted) days trying to get the Kingston cards working!
My working boot commands would not load uImage from /boot/uImage on the new SDHC cards. (the reported error was could not find /boot/uImage, followed by the infamous bad magic number, but the prime fault is that uboot could not load the uImage).
Even trying this manually, with lots of mmcinits before the ext2load command did not work, nor did power off/on uboot reset and all the other advice given here.
HOWEVER using:- ext2ls mmc 0:1 / boot returns "uImage" !!!
Why has uboot an aversion to doing a ext2load on the Kingston cards, (my Transcend works fine!)
Several years ago I did some work with an Atmel NGW100 ref design, a small module with two NICS, USB and an SD card. There was lots of problems at the time with SD card support on the Atmel Uboot, it was very very picky over which manufactures' cards it would work with and the size of card, (sub 1gb only). I had hoped by now that things had improved, and Uboot and SD cards was more robust.
Unfortunately looking at the Plug forum and Googling "bad magic number" for example it seems that on many embedded systems, using uboot and SD cards, things are still very flakey.
I am a little suspicious of the output of the mkimage utility. ASAIK mkimage applies a "header" including a CRC, to the compiled kernel binary thus:-
In the first form (with "-l" option) mkimage lists the information contained in the header of an existing U-Boot image; this includes checksum verification:
tools/mkimage -l image
-l ==> list image header information
The second form (with "-d" option) is used to build a U-Boot image from a "data file" which is used as image payload:
tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \
-n name -d data_file image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
I did a mkimage -l on my modified uImage on my x8s box I cross compiled on and it returned
debsilch:/home/patrick/sheeva/orion/arch/arm/boot# mkimage -l uImage
Image Name: Linux-2.6.32-rc7-00010-g1cb9f9b-
Created: Sun Dec 13 18:15:25 2009
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2291300 Bytes = 2237.60 kB = 2.19 MB
Load Address: 0x00008000
Entry Point: 0x00008000
The parameters for mkimage are buried somewhere in the cross compiler, so I haven't changed them. Note that the uImage load and entry address is set to 0x08000 I am using 0x80000. It did not appear to make any difference using the Transcend, so why should it make any odds to the Kingston.
Accordin to the Kingston PR blurb, it is supposed to be using wear levelling. Not all SDHC cards do this. I can find no mention of wear levelling in the Transcend literature. Is there a timing problem ?
If the Kingston does employ wear levelling, then I suppose that there may have to be an additional level of lookup tables in the Kingston control chip, although it might only be slower on a write to sdhc memory, the cell address would then be in the lookup table for the read. It is a pity that the SDHC manufacturers guard this info so closely, it would be nice to find out what is really going on!
Please can anyone suggest why the Transcend works on ext2load and the Kingston doesn't? and why does ext2ls work OK on the Kingston, showing that uboot CAN find the file if it wants to?
regards
Patrick
