SheevaPlug does not boot from SD - Bad Data CRC

[Imran-UK]

Hi,

I returned from a holiday to find my SheevaPlug in a poor state. It was pinging but not responding to ssh. On connecting the USB serial console I saw the following:

Code:

mmcblk0: error -110 sending remvsdio mvsdio: FIFO_EMPTY bit missing
mmcblmvsdio mvsdio: FIFO_EMPTY bit missing
mmcesponse 0x40, sector 1332004
mvsdio mvsdio: FIFO_EMPTY bit missing
m response 0xk0, sector 1332005
mvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -110 sending read/write comman0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector
mmcblk0: error -110 sending read/write commend_remcblk0, sector 1332007
mvsdio mvsdio: FIFO_EMPTY bit missi
mvsdio mvsdio: FIFO_EMrror, dev mmcblk0, sector 2680928
mvsdio mvsdio: FIFO_g read/writmvsdio mvsdio: FIFing read/wrmvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -110 sewrite command, response 0x400d00, card status 0x400d00
end_request: I/O ercblk0, sector 2680931
mvsdio mvsdio:
              mvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -113
I/O error, dev mmcblk0, sector 2680934
rying using single block read
write command, response 0xd00, card status 0x400d00
end_request: I/O error, dev mmcblg
mmcblk0: error -110 sending read/write commvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -110 sending read/write c0
end_request: I/O error, delk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector 1332003
cblk0: error -110 sending read/write command,end_requestmvsdio mvsdio: FIFO_EMPTY bi0x400d00, card status 0x400d00
 1332005

mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sectmvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_rtor 1332007
mvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: retrying using single block read
issing
mm00, card status 0x400d00
end_request: I/O error, dev mmcblk0, mvsdio mvsdio: FIFO_EMPTY bit missing
mmcblk0: error -110 sending read/write command, responseard status 0x400d00
end_request: I/O error, dev mmcblk0, secto

My plug runs Debian Lenny from the SD card and should automatically boot into it. On a reboot, it boots into Ubuntu 9.04 which is in the NAND.

I stopped the autoboot and tried to boot into Debian manually but got this error:

Code:

Marvell>> run bootcmd_mmc
SDHC found. Card desciption is:
Manufacturer:       0x1b, OEM "SM"
Product name:       "00000", revision 1.0
Serial number:      1948856046
Manufacturing date: 7/2009
CRC:                0x00, b0 = 0

2620504 bytes read
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.30.2
   Created:      2009-07-23   1:53:36 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2620440 Bytes =  2.5 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

The SD card is pretty new, I bought it with the SheevaPlug last year.

It seems I have a dodgy SD card and it has corrupted the kernel image. After a bit of Googling, my next step was going to try and copy over a new kernel image. However if the SD card is not reliable I may be facing the same problem soon.

Any advice? Thanks!

[NewIT_Marcus]

To update - or refresh - the kernel on the SD card - you can download from here:

http://sheeva.with-linux.com/sheeva/

* Boot from NAND
* Mount SD card partition(s) ( mount /dev/mmcblk0p1 /mnt/mmc-kernel-partition )
* Download kernel and modules if required
* Write kernel and modules
* Test

[Imran-UK]

Well, I have had a frustrating week trying various ways to get the SheevaPlug to boot Debian. Without success :-(

I have tried Martin Michlmayr's HOWTO here http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html but both Lenny and Squeeze installs fail for various reasons. One reason for Squeeze was dodgy installer images as documented here: http://lists.debian.org/debian-arm/2010/09/msg00041.html

I have tried two seperate SD cards, one Toshiba 4GB and another Integral 8GB. I updated the U-Boot image to version 3.4.27 from 3.4.23

Code:

Marvell>> version
U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27 - pingtoo patch.01

I tried instead to use the pre-prepared Lenny tarball method here: http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html

My SD card partition layout is slightly modified from the HOWTO:

Code:

/dev/mmcblk0p1 /boot type ext2
/dev/mmcblk0p3 / type ext2
/dev/mmcblk0p4 /var ext2

The error I always get is:

Code:

        __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: SHEEVA PLUG LE

U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM CS[1] base 0x10000000   size 256MB
DRAM Total size 512MB  16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0
SDHC found. Card desciption is:
Manufacturer:       0x27, OEM "PH"
Product name:       "SD08G", revision 2.0
Serial number:      271100857
Manufacturing date: 7/2010
CRC:                0x00, b0 = 0

** Invalid partition type "" (expect "U-Boot")

** Invalid partition type "" (expect "U-Boot")
## Booting image at 00800000 ...
Bad Magic Number

I have a feeling it might be something in my U-Boot env (MAC obscured):

Code:

baudrate=115200
loads_echo=0
ipaddr=10.4.50.165
serverip=10.4.50.5
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
run_diag=yes
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
ethaddr=00:50:43:xx:xx:xx
ethmtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
ethact=egiga0
bootargs_console=console=ttyS0,115200
bootargs_root=root=/dev/mmcblk0p3
bootcmd_mmc=mmcinit; ext2load mmc 0:1 0x01100000 /uInitrd; ext2load mmc 0:1 0x00800000 /uImage
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x00800000 0x01100000
arcNumber=2097
stdin=serial
stdout=serial
stderr=serial
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no
bootargs=console=ttyS0,115200 root=/dev/mmcblk0p3

Any ideas? I'm tearing my hair out here. My next step was going to try a TFTP boot. My google-fu is weak and I keep running into dead-ends.

BTW, ext2ls does not seem to work. Does this point to an issue with my SD card?

Code:

Marvell>> ext2ls mmc 0:1 /
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **

Another oddity I noticed with the SDcard is a couple of "unusable" areas reported by cfdisk:

Code:

                                     Unusable                             1.05
    mmcblk1p1   Boot        Primary   Linux ext2                         199.23
    mmcblk1p2               Primary   Linux swap / Solaris               511.71
    mmcblk1p3               Primary   Linux ext2                        4300.22
    mmcblk1p4               Primary   Linux ext2                        2972.72
                                      Unusable                             1.05

Just tried an experiment with fatload on a different SD card:

Code:

Marvell>> fatls mmc 0:1
    85107   config-2.6.32-5-kirkwood
  5217825   initrd.img
  5217825   initrd.img-2.6.32-5-kirkwood
  1009318   system.map-2.6.32-5-kirkwood
  1444216   uimage
  5217889   uinitrd
  1444152   vmlinuz
  1444152   vmlinuz-2.6.32-5-kirkwood

and change ext2load to fatload...

Code:

Marvell>> setenv bootcmd_mmc 'mmcinit; fatload mmc 0:1 0x01100000 /uInitrd; fatload mmc 0:1 0x00800000 /uImage'

...it boots! So my conclusion is that there is either a problem with the ext2load routine in UBoot or something about my ext2 partitions?

Code:

Marvell>> run bootcmd
SDHC found. Card desciption is:
Manufacturer:       0x02, OEM "TM"
Product name:       "SD04G", revision 6.1
Serial number:      2967450160
Manufacturing date: 5/2010
CRC:                0x00, b0 = 0
reading /uInitrd

5217889 bytes read
reading /uImage

1444216 bytes read
## Booting image at 00800000 ...
   Image Name:   Debian kernel
   Created:      2010-06-13  12:32:01 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1444152 Bytes =  1.4 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 01100000 ...
   Image Name:   Debian ramdisk
   Created:      2010-06-13  12:32:02 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5217825 Bytes =  5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32-5-kirkwood (Debian 2.6.32-13) (maks@debian.org) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 Fri May 21 05:44:29 UTC 2010

[NewIT_Marcus]

I think the errors your originally reported point to a problem (wear?) with the original SD card. Do you now have the system working when booting from an alternate SD card, but not with the original SD card?

[Imran-UK]

Hi Marcus,

I currently have no working system. I am stuck as above. It only booted because I copied the contents of /boot to a spare SD card containing a single partition formatted as FAT16. Later in the boot stage it complains about not being able to find the root filesystem. As the root is going to be on an ext2 partition I think I need to get to the bottom of why ext2ls is not working.

The original card did appear to have errors. I sent it back to Integral who checked the card and replaced it with a 8GB Class 6 SDHC card.

I now have a Toshiba 4GB SDHC card (with a single FAT16 4GB partition) and the 8GB Integral SDHC card (with the unpacked Debian Lenny tarball on it).

The PSU recently failed on this SheevaPlug which was replaced under warranty.

Thanks

[Imran-UK]

I tried the manual tarball method with a USB stick instead (good quality Toshiba 2GB). This also failed to load the kernel:

Code:

Marvell>> run bootcmd
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00800000 ...
Bad Magic Number

[NewIT_Marcus]

I am confused. You said:

I currently have no working system. I am stuck as above.

But "above" you also said:

Just tried an experiment with fatload on a different SD card:

Code:

Marvell>> fatls mmc 0:1
    85107   config-2.6.32-5-kirkwood
  5217825   initrd.img
  5217825   initrd.img-2.6.32-5-kirkwood
  1009318   system.map-2.6.32-5-kirkwood
  1444216   uimage
  5217889   uinitrd
  1444152   vmlinuz
  1444152   vmlinuz-2.6.32-5-kirkwood

and change ext2load to fatload...

Code:

Marvell>> setenv bootcmd_mmc 'mmcinit; fatload mmc 0:1 0x01100000 /uInitrd; fatload mmc 0:1 0x00800000 /uImage'

...it boots! So my conclusion is that there is either a problem with the ext2load routine in UBoot or something about my ext2 partitions?

I asked you to confirm that there was a scenario in which you have a bootable SD card, because of the above.

If you have one booting SD card (albeit with different partitions or file format than you would like), then it does seem that there is some success in reading SD cards - or that SD card, at least.

Of the errors that you have reported, some I have seen before, and some I have not. In particular, the key error that I have not seen before is:

Code:

** Invalid partition type "" (expect "U-Boot")

It's not clear at this point in the boot process if it is U-Boot or the [successfully?] loaded kernel that would give this error, but U-Boot must be considered a suspect.

If you can boot to NAND you should be able to mount each SD card / partition in turn and test it for reading and writing.

Code:

mount /dev/mmcblk0p1 /mnt/SD-partition1

etc.

If the SD cards work OK, you could download one of our images and use our environment variables to attempt to boot:

http://www.newit.co.uk/drive-images/
http://www.newit.co.uk/forum/index.php/board,9.0.html

You can swap SD cards (and what is on the SD cards), and you report that you can change your version of U-Boot, so there are enough variables there to work with and narrow down the source of the problem.

[Imran-UK]

Thanks Marcus, I fixed the problem by writing one of the Debian Squeeze 8GB Integral Ultima images AND also manually checking every uboot envvar against here: http://www.newit.co.uk/forum/index.php/topic,194.0.html

Since both variables were changed I'm not sure what the problem is but I suspect I was missing a crucial uboot envvar.

Thank you very much for your help.

A couple of queries -

1. is there an automatic way to get a list of uboot variables in key=value format to be applied to uboot? eg. copy a file of key=value to a USB stick or SDcard and source it from within uboot?

2. One uboot env var could not be set, the final "bootm 0x00800000 0x01100000"" was missing. The key/value was: "recover2=run recover3; setenv bootcmd $(real_bootcmd); saveenv; setenv bootargs $(bootargs_console) $(mtdpartitions) root=/dev/ram0 rw ramdisk=0x01100000,8M install_type=nand; bootm 0x00800000 0x01100000" could not be set with a warning of "too many arguments, 16 max" - is this a function of my uboot version perhaps? I downgraded to 3.4.19 as I read reports of people having more reliability with that.

Thank you.

[NewIT_Marcus]

Thanks Marcus, I fixed the problem by writing one of the Debian Squeeze 8GB Integral Ultima images AND also manually checking every uboot envvar against here: http://www.newit.co.uk/forum/index.php/topic,194.0.html

Since both variables were changed I'm not sure what the problem is but I suspect I was missing a crucial uboot envvar.

Thank you very much for your help.

A couple of queries -

1. is there an automatic way to get a list of uboot variables in key=value format to be applied to uboot? eg. copy a file of key=value to a USB stick or SDcard and source it from within uboot?

Not really. Keeping a copy of your environment variables should be considered just as important as other aspects of backup; you can copy & paste your "good" environment variables into a text file and put that somewhere safe. I have a file somewhere that has our standard settings in a variable='parameter' format, which I think is what you are asking, but for the sake of 30 or so settings, you may as well perform the steps manually. (Yes, you could automate it with some kind of text processing program, but of course you'd need to test / verify your output and doing it manually won't take any longer)

2. One uboot env var could not be set, the final "bootm 0x00800000 0x01100000"" was missing. The key/value was: "recover2=run recover3; setenv bootcmd $(real_bootcmd); saveenv; setenv bootargs $(bootargs_console) $(mtdpartitions) root=/dev/ram0 rw ramdisk=0x01100000,8M install_type=nand; bootm 0x00800000 0x01100000" could not be set with a warning of "too many arguments, 16 max" - is this a function of my uboot version perhaps? I downgraded to 3.4.19 as I read reports of people having more reliability with that.

Thank you.

the recover* variables are used during the flash process only; once the plug has been flashed, strictly speaking, they aren't required. However, if it became necessary, you could insert a suitable USB stick (with a rootfs, kernel, modules and initrd), and from the Marvell>> prompt type:

Code:

run recover1

Doing so will wipe your NAND and rewrite it with the rootfs from the USB stick. So don't do it unless you know exactly what you are doing. (See here and here. Any variations in the values of the recover* variables can be ignored, unless you are reflashing. They are only used for reflashing.

It is possible to set and environment variable to a long string (with more than 16 separators / spaces) by defining variable1, then variable2, then setting variable 3 to be something like '$(variable1) $(variable2)' (I'm not 100% sure of the syntax without double-checking). For the reasons mentioned above, it's only a side issue for you right now. Changing your version of U-Boot won't affect the results of setting a variable with many separators.

We do recommend U-Boot 3.4.23 (for non-eSATA plugs); it has eliminates a bug that is quite visible in earlier versions, where environment variables sometimes get split into two. You'll know it kicked in when one of your environment variables has a value a000