new uboot version 3.4.25

[superpat]

Hi pingtoo.

Thanks for all your work on this problem.

Here are the results of testing using your debug enabled u-boot.

I have annotated  the putty printout with notes of  points of interest! Looking at the preview, I see the notes have wrapped and are below the line where I put them, but you should be able to work out what I was trying to point out!

Firstly for comparison reference   here is a directory of my SDHC card  root file system taken on my Linux box

You will see there is a uImage in /boot.  ( There is a second copy in / ,  (this enables me to load uImage)

debsilch:/media/disk# ls -la
total 49196
drwxr-xr-x 21 root root     4096 2010-01-01 16:32 .
drwxr-xr-x  4 root root     4096 2010-01-05 09:47 ..
drwxr-xr-x  2 root root     4096 2009-12-03 12:37 bin
drwxr-xr-x  2 root root     4096 2010-01-01 15:51 boot
drwxr-xr-x  4 root root     4096 2010-01-01 16:36 dev
drwxr-xr-x 42 root root     4096 2010-01-01 16:36 etc
drwxr-xr-x  2 root root     4096 2009-08-31 04:45 home
drwxr-xr-x 11 root root     4096 2009-12-03 12:37 lib
drwx------  2 root root    16384 2010-01-01 15:24 lost+found
drwxr-xr-x  2 root root     4096 2009-12-03 12:33 media
drwxr-xr-x  2 root root     4096 2009-08-31 04:45 mnt
drwxr-xr-x  2 root root     4096 2009-12-03 12:33 opt
-rw-r--r--  1 root root    13840 2009-12-03 12:37 PackageList.txt
drwxr-xr-x  2 root root     4096 2009-08-31 04:45 proc
drwxr-xr-x  2 root root     4096 2009-12-03 12:33 root
-rw-r--r--  1 root root 47891458 2010-01-01 15:26 rootfs.tar.gz
drwxr-xr-x  2 root root     4096 2009-12-03 12:37 sbin
drwxr-xr-x  2 root root     4096 2008-09-16 08:48 selinux
drwxr-xr-x  2 root root     4096 2009-12-03 12:33 srv
drwxr-xr-x  2 root root     4096 2008-08-12 15:26 sys
drwxrwxrwt  4 root root     4096 2010-01-01 16:36 tmp
-rwxr-xr-x  1 root root  2309636 2010-01-01 16:32 uImage
drwxr-xr-x 11 root root     4096 2009-12-03 12:36 usr
drwxr-xr-x 13 root root     4096 2009-12-03 12:33 var

debsilch:/media/disk# cd boot
debsilch:/media/disk/boot# ls -la
total 2268
drwxr-xr-x  2 root root    4096 2010-01-01 15:51 .
drwxr-xr-x 21 root root    4096 2010-01-01 16:32 ..
-rwxrwxrwx  1 root root 2309636 2010-01-01 15:51 uImage
debsilch:/media/disk/boot#

Here is the output from putty for your debug U-boot.

Hit any key to stop autoboot:  3  0

Marvell>>     usb start]


(Re)start USB...

USB:   scanning bus for devices... 2 USB Device(s) found

       scanning bus for storage devices... 1 Storage Device(s) found

Marvell>> fatload usb 0:1 0x1600000 /ext2-debug-u-boot.bin


reading /ext2-debug-u-boot.bin

..............................................



474076 bytes read

Marvell>> go 0x1600000


## Starting application at 0x01600000 ...



         __  __                      _ _

        |  \/  | __ _ _ ____   _____| | |

        | |\/| |/ _` | '__\ \ / / _ \ | |

        | |  | | (_| | |   \ V /  __/ | |

        |_|  |_|\__,_|_|    \_/ \___|_|_|

 _   _     ____              _

| | | |   | __ )  ___   ___ | |_

| | | |___|  _ \ / _ \ / _ \| __|

| |_| |___| |_) | (_) | (_) | |_

 \___/    |____/ \___/ \___/ \__|

 ** MARVELL BOARD: SHEEVA PLUG LE



U-Boot 1.1.4 (Jan  4 2010 - 21:45:00) Marvell version: 3.4.27



U-Boot code: 01600000 -> 0167FFF0  BSS: -> 016CFEE0



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 24M - 0M are saved for the U-Boot usage.

Mem malloc Initialization (24M - 23M): 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:  3  0

Marvell>> version




U-Boot 1.1.4 (Jan  4 2010 - 21:45:00) Marvell version: 3.4.27 - pingtoo ext2 testing.01
  << YOUR DEBUG VERSION
Marvell>> mmcinit


SDHC found. Card desciption is:

Manufacturer:       0x27, OEM "PH"

Product name:       "SD8GB", revision 2.0
  << KINGSTON 8GB TYPE 6 SDHC  CARD
Serial number:      2953847158

Manufacturing date: 8/2009

CRC:                0x00, b0 = 0

Marvell>> ext2ls mmc 0

 <<< SAME COMMAND A YOU USED IN YOUR EXAMPLE
 <2, 0, 204>

revision_level = 0x1, inode_size = 0x100

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

ext2fs_read_block 000003e3

 <7960, 0, 8>

ext2fs_read_block 000003e3

 <7960, 8, 1>

iterate >.<

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

<DIR>       4096 .

ext2fs_read_block 000003e3

 <7960, 12, 8>

ext2fs_read_block 000003e3

 <7960, 20, 2>

iterate >..<

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

<DIR>       4096 ..

ext2fs_read_block 000003e3

 <7960, 24, 8>

ext2fs_read_block 000003e3

 <7960, 32, 10>

iterate >lost+found<

ext2fs read inode 10

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 10

 <3869, 0, 128>

<DIR>      16384 lost+found

ext2fs_read_block 000003e3

 <7960, 44, 8>

ext2fs_read_block 000003e3

 <7960, 52, 13>

iterate >rootfs.tar.gz<

ext2fs read inode 11

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 11

 <3869, 256, 128>

        47891458 rootfs.tar.gz

ext2fs_read_block 000003e3

 <7960, 68, 8>

ext2fs_read_block 000003e3

 <7960, 76, 15>

iterate >PackageList.txt<

ext2fs read inode 12

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 12

 <3870, 0, 128>

           13840 PackageList.txt

ext2fs_read_block 000003e3

 <7960, 92, 8>

ext2fs_read_block 000003e3

 <7960, 100, 3>

iterate >bin<

ext2fs read inode 163840

ext2fs read blockgroup

 <9, 128, 32>

ext2fs read inode blkno 0 blkoff 0

 <5242896, 0, 128>

<DIR>       4096 bin

ext2fs_read_block 000003e3

 <7960, 104, 8>

ext2fs_read_block 000003e3

 <7960, 112, 4>

iterate >boot<

ext2fs read inode 393216

ext2fs read blockgroup

 <11, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <12582928, 0, 128>

<DIR>       4096 boot

ext2fs_read_block 000003e3

 <7960, 116, 8>

ext2fs_read_block 000003e3

 <7960, 124, 3>

iterate >dev<

ext2fs read inode 172032

ext2fs read blockgroup

 <9, 160, 32>

ext2fs read inode blkno 0 blkoff 0

 <5505040, 0, 128>

<DIR>       4096 dev

ext2fs_read_block 000003e3

 <7960, 128, 8>

ext2fs_read_block 000003e3

 <7960, 136, 3>

iterate >etc<

ext2fs read inode 409600

ext2fs read blockgroup

 <11, 64, 32>

ext2fs read inode blkno 0 blkoff 0

 <13107216, 0, 128>

<DIR>          0 etc

ext2fs_read_block 000003e3

 <7960, 140, 8>

ext2fs_read_block 000003e3

 <7960, 148, 4>

iterate >home<

ext2fs read inode 344064

ext2fs read blockgroup

 <10, 320, 32>

ext2fs read inode blkno 0 blkoff 0

 <11010064, 0, 128>

<DIR>       4096 home

ext2fs_read_block 000003e3

 <7960, 152, 8>

ext2fs_read_block 000003e3

 <7960, 160, 3>

iterate >lib<

ext2fs read inode 294912

ext2fs read blockgroup

 <10, 128, 32>

ext2fs read inode blkno 0 blkoff 0

 <9437200, 0, 128>

<DIR>       4096 lib

ext2fs_read_block 000003e3

 <7960, 164, 8>

ext2fs_read_block 000003e3

 <7960, 172, 5>

iterate >media<

ext2fs read inode 311296

ext2fs read blockgroup

 <10, 192, 32>

ext2fs read inode blkno 0 blkoff 0

 <9961488, 0, 128>

<DIR>       4096 media

ext2fs_read_block 000003e3

 <7960, 180, 8>

ext2fs_read_block 000003e3

 <7960, 188, 3>

iterate >mnt<

ext2fs read inode 16384

ext2fs read blockgroup

 <8, 64, 32>

ext2fs read inode blkno 0 blkoff 0

 <524304, 0, 128>

<DIR>       4096 mnt

ext2fs_read_block 000003e3

 <7960, 192, 8>

ext2fs_read_block 000003e3

 <7960, 200, 3>

iterate >opt<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <4194320, 0, 128>

<DIR>       4096 opt

ext2fs_read_block 000003e3

 <7960, 204, 8>

ext2fs_read_block 000003e3

 <7960, 212, 4>

iterate >proc<

ext2fs read inode 81920

ext2fs read blockgroup

 <8, 320, 32>

ext2fs read inode blkno 0 blkoff 0

 <2621456, 0, 128>

<DIR>       4096 proc

ext2fs_read_block 000003e3

 <7960, 216, 8>

ext2fs_read_block 000003e3

 <7960, 224, 4>

iterate >root<

ext2fs read inode 49152

ext2fs read blockgroup

 <8, 192, 32>

ext2fs read inode blkno 0 blkoff 0

 <1572880, 0, 128>

<DIR>       4096 root

ext2fs_read_block 000003e3

 <7960, 228, 8>

ext2fs_read_block 000003e3

 <7960, 236, 4>

iterate >sbin<

ext2fs read inode 32768

ext2fs read blockgroup

 <8, 128, 32>

ext2fs read inode blkno 0 blkoff 0

 <1048592, 0, 128>

<DIR>       4096 sbin

ext2fs_read_block 000003e3

 <7960, 240, 8>

ext2fs_read_block 000003e3

 <7960, 248, 7>

iterate >selinux<

ext2fs read inode 98304

ext2fs read blockgroup

 <8, 384, 32>

ext2fs read inode blkno 0 blkoff 0

 <3145744, 0, 128>

<DIR>       4096 selinux

ext2fs_read_block 000003e3

 <7960, 256, 8>

ext2fs_read_block 000003e3

 <7960, 264, 3>

iterate >srv<

ext2fs read inode 335872

ext2fs read blockgroup

 <10, 288, 32>

ext2fs read inode blkno 0 blkoff 0

 <10747920, 0, 128>

<DIR>          0 srv

ext2fs_read_block 000003e3

 <7960, 268, 8>

ext2fs_read_block 000003e3

 <7960, 276, 3>

iterate >sys<

ext2fs read inode 303104

ext2fs read blockgroup

 <10, 160, 32>

ext2fs read inode blkno 0 blkoff 0

 <9699344, 0, 128>

<DIR>          0 sys

ext2fs_read_block 000003e3

 <7960, 280, 8>

ext2fs_read_block 000003e3

 <7960, 288, 3>

iterate >tmp<

ext2fs read inode 466944

ext2fs read blockgroup

 <11, 288, 32>

ext2fs read inode blkno 0 blkoff 0

 <14942224, 0, 128>

<DIR>          0 tmp

ext2fs_read_block 000003e3

 <7960, 292, 8>

ext2fs_read_block 000003e3

 <7960, 300, 3>

iterate >usr<

ext2fs read inode 155648

ext2fs read blockgroup

 <9, 96, 32>

ext2fs read inode blkno 0 blkoff 0

 <4980752, 0, 128>

<DIR>       4096 usr

ext2fs_read_block 000003e3

 <7960, 304, 8>

ext2fs_read_block 000003e3

 <7960, 312, 3>

iterate >var<

ext2fs read inode 319488

ext2fs read blockgroup

 <10, 224, 32>

ext2fs read inode blkno 0 blkoff 0

 <10223632, 0, 128>

<DIR>          0 var

ext2fs_read_block 000003e3

 <7960, 316, 8>

ext2fs_read_block 000003e3

 <7960, 324, 6>

iterate >uImage<

ext2fs read inode 13

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 13

 <3870, 256, 128>

         2309636 uImage




Marvell>> ext2ls mmc 0:1 /boot << ATTEMPTING TO LIST THE CONTENTS OF /boot


 <2, 0, 204>

revision_level = 0x1, inode_size = 0x100

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

Iterate dir boot

ext2fs_read_block 000003e3

 <7960, 0, 8>

ext2fs_read_block 000003e3

 <7960, 8, 1>

iterate >.<

ext2fs_read_block 000003e3

 <7960, 12, 8>

ext2fs_read_block 000003e3

 <7960, 20, 2>

iterate >..<

ext2fs_read_block 000003e3

 <7960, 24, 8>

ext2fs_read_block 000003e3

 <7960, 32, 10>

iterate >lost+found<

ext2fs_read_block 000003e3

 <7960, 44, 8>

ext2fs_read_block 000003e3

 <7960, 52, 13>

iterate >rootfs.tar.gz<

ext2fs_read_block 000003e3

 <7960, 68, 8>

ext2fs_read_block 000003e3

 <7960, 76, 15>

iterate >PackageList.txt<

ext2fs_read_block 000003e3

 <7960, 92, 8>

ext2fs_read_block 000003e3

 <7960, 100, 3>

iterate >bin<

ext2fs_read_block 000003e3

 <7960, 104, 8>

ext2fs_read_block 000003e3

 <7960, 112, 4>

iterate >boot<

ext2fs read inode 393216

ext2fs read blockgroup

 <11, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <12582928, 0, 128>

ext2fs_read_block 00081000

 <4227072, 0, 8>

ext2fs_read_block 00081000

 <4227072, 8, 1>

iterate >.<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <4194320, 0, 128>

<DIR>       4096 .

ext2fs_read_block 00081000

 <4227072, 12, 8>

ext2fs_read_block 00081000

 <4227072, 20, 2>

iterate >..<

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

<DIR>       4096 ..
          << FAILURE NO LISTING OF /boot/uImage

Marvell>> <INTERRUPT>



Marvell>> ext2load mmc 0 0x800000 /boot/uImage

  <<ATTEMPTING TO LOAD uImage FROM /boot
  <2, 0, 204>

revision_level = 0x1, inode_size = 0x100

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

Iterate dir boot

ext2fs_read_block 000003e3

 <7960, 0, 8>

ext2fs_read_block 000003e3

 <7960, 8, 1>

iterate >.<

ext2fs_read_block 000003e3

 <7960, 12, 8>

ext2fs_read_block 000003e3

 <7960, 20, 2>

iterate >..<

ext2fs_read_block 000003e3

 <7960, 24, 8>

ext2fs_read_block 000003e3

 <7960, 32, 10>

iterate >lost+found<

ext2fs_read_block 000003e3

 <7960, 44, 8>

ext2fs_read_block 000003e3

 <7960, 52, 13>

iterate >rootfs.tar.gz<

ext2fs_read_block 000003e3

 <7960, 68, 8>

ext2fs_read_block 000003e3

 <7960, 76, 15>

iterate >PackageList.txt<

ext2fs_read_block 000003e3

 <7960, 92, 8>

ext2fs_read_block 000003e3

 <7960, 100, 3>

iterate >bin<

ext2fs_read_block 000003e3

 <7960, 104, 8>

ext2fs_read_block 000003e3

 <7960, 112, 4>

iterate >boot<

Iterate dir uImage

ext2fs read inode 393216

ext2fs read blockgroup

 <11, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <12582928, 0, 128>

ext2fs_read_block 00081000

 <4227072, 0, 8>

ext2fs_read_block 00081000

 <4227072, 8, 1>

iterate >.<

ext2fs_read_block 00081000

 <4227072, 12, 8>

ext2fs_read_block 00081000

 <4227072, 20, 2>

iterate >..<



** Unable to read "/boot/uImage" from mmc 0:1 **
  << FAIURE CANNOT LOAD uIimage FROM /boot/

Marvell>>

This indicates exactly the "standard" way this card / u-boot fails. I hope this ouput is of use to you.

What would you like me to try next?

cheers


Patrick

[pingtoo]

@superpat,

Thanks for the info. currently in office I am not able to check the code with your result. Will look at it once go back home.

Regards,

pingtoo.

[pingtoo]

@superpat,

Hi, after some eye bleeding reading of source code and your post result, I found something Not 100% sure yet but can you help me test this, please copy your uImage (does not matter from where) into your /opt. I notice this in your post,

Code:

ext2fs_read_block 000003e3

 <7960, 200, 3>

iterate >opt<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

And

Code:

iterate >boot<

ext2fs read inode 393216

ext2fs read blockgroup

 <11, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <12582928, 0, 128>

ext2fs_read_block 00081000

 <4227072, 0, 8>

ext2fs_read_block 00081000

 <4227072, 8, 1>

iterate >.<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

seems to indicate for whatever reason your /boot/. seems to be point to /opt's inode number, I need your help to confirm this is the case. I suspect either during creation (untar) or u-boot code have bug. with your help testing, If I can confirm my guess is right then I will try to generate a new debug version which will print out the inode information when u-boot read out from storage. from there may be we can determine whither it is u-boot somehow had a memory corruption or somehow during your creation corrupted data went into file system. 

Regards,

pingtoo.

[superpat]

@pingtoo

Hi,

Some interesting stuff! I did some reading about inodes, ls and stat, trying to remember what I learnt many years ago on my DEC Ultrix system manglers course!

I took my 8GB Kingston card out of the Sheevaplug and mounted it in one of my x86 Linux boxes  (Debian distrib)

I then did   ls -i and  stat of the directories in dispute 

Here are the results:-

debsilch:/mnt/plug#
debsilch:/mnt/plug# ls -i
163841 bin       11 lost+found         49153 root      466945 tmp
393217 boot  311297 media            12 rootfs.tar.gz      14 uImage
172033 dev    16385 mnt            32769 sbin      155649 usr
409601 etc   131073 opt            98305 selinux      319489 var
344065 home      13 PackageList.txt  335873 srv
294913 lib    81921 proc        303105 sys

debsilch:/mnt/plug# ls -i boot
393218 uImage
debsilch:/mnt/plug#


debsilch:/mnt/plug# ls -i opt
debsilch:/mnt/plug#
debsilch:/mnt/plug# ls -i opt
debsilch:/mnt/plug#
debsilch:/mnt/plug#
debsilch:/mnt/plug#
debsilch:/mnt/plug# stat boot
  File: `boot'
  Size: 4096         Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d   Inode: 393217      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-06 08:54:58.000000000 +0000
Modify: 2010-01-01 15:51:20.000000000 +0000
Change: 2010-01-01 15:51:20.000000000 +0000


debsilch:/mnt/plug# stat boot/uImage
  File: `boot/uImage'
  Size: 2309636      Blocks: 4520       IO Block: 4096   regular file
Device: 801h/2049d   Inode: 393218      Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-01 16:32:44.000000000 +0000
Modify: 2010-01-01 15:51:20.000000000 +0000
Change: 2010-01-01 16:07:59.000000000 +0000

debsilch:/mnt/plug# stat opt
  File: `opt'
  Size: 4096         Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d   Inode: 131073      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-06 08:55:59.000000000 +0000
Modify: 2009-12-03 12:33:56.000000000 +0000
Change: 2010-01-01 15:26:27.000000000 +0000
debsilch:/mnt/plug#

You will see that the inode for the boot directory is given by stat on an x86 m/c is

boot = 393217
boot/uImage = 393298

Also  ls -i  is exactly the same/


For the empty opt directory

opt=131073

Now  looking at the results given by your debug u-boot,

the inode for the boot directory is given as 

boot = 393216

and for  the opt directory

opt=131072

These are showing as ONE less in each case, than the value obtained on the x86 system. I suppose it depends on whether the count starts at  zero or one  on each system!

However, what appears to be written on my  Kingston card is that  a good file system, with NO cross linked or dual  inodes.  You can see that (on a x86 system) the inodes are as they should be. I would suggest my RFS on the sdhc card is not corrupt, (at least not in an obvious way).

I am a bit unclear of the methodology of the next test you wish me to do.  Please advise steps you wish me to try.

YOU WERE CORRECT!  SEE NEXT REPLY FOR MORE TEST RESULTS.

thanks again

regards

Patrick

[superpat]

@pingtoo

YOU ARE CORRECT!

I copied the file uImage into /opt, renaming it uImageb   for clarity.

I then installed the card in the plug, loaded up your debug u-boot and did a ext2ls of  /opt

Marvell>> ext2ls mmc 0:1 /opt


 <2, 0, 204>

revision_level = 0x1, inode_size = 0x100

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

Iterate dir opt

ext2fs_read_block 000003e3

 <7960, 0, 8>

ext2fs_read_block 000003e3

 <7960, 8, 1>

iterate >.<

ext2fs_read_block 000003e3

 <7960, 12, 8>

ext2fs_read_block 000003e3

 <7960, 20, 2>

iterate >..<

ext2fs_read_block 000003e3

 <7960, 24, 8>

ext2fs_read_block 000003e3

 <7960, 32, 10>

iterate >lost+found<

ext2fs_read_block 000003e3

 <7960, 44, 8>

ext2fs_read_block 000003e3

 <7960, 52, 13>

iterate >rootfs.tar.gz<

ext2fs_read_block 000003e3

 <7960, 68, 8>

ext2fs_read_block 000003e3

 <7960, 76, 15>

iterate >PackageList.txt<

ext2fs_read_block 000003e3

 <7960, 92, 8>

ext2fs_read_block 000003e3

 <7960, 100, 3>

iterate >bin<

ext2fs_read_block 000003e3

 <7960, 104, 8>

ext2fs_read_block 000003e3

 <7960, 112, 4>

iterate >boot<

ext2fs_read_block 000003e3

 <7960, 116, 8>

ext2fs_read_block 000003e3

 <7960, 124, 3>

iterate >dev<

ext2fs_read_block 000003e3

 <7960, 128, 8>

ext2fs_read_block 000003e3

 <7960, 136, 3>

iterate >etc<

ext2fs_read_block 000003e3

 <7960, 140, 8>

ext2fs_read_block 000003e3

 <7960, 148, 4>

iterate >home<

ext2fs_read_block 000003e3

 <7960, 152, 8>

ext2fs_read_block 000003e3

 <7960, 160, 3>

iterate >lib<

ext2fs_read_block 000003e3

 <7960, 164, 8>

ext2fs_read_block 000003e3

 <7960, 172, 5>

iterate >media<

ext2fs_read_block 000003e3

 <7960, 180, 8>

ext2fs_read_block 000003e3

 <7960, 188, 3>

iterate >mnt<

ext2fs_read_block 000003e3

 <7960, 192, 8>

ext2fs_read_block 000003e3

 <7960, 200, 3>

iterate >opt<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <4194320, 0, 128>

ext2fs_read_block 00081000

 <4227072, 0, 8>

ext2fs_read_block 00081000

 <4227072, 8, 1>

iterate >.<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <4194320, 0, 128>

<DIR>       4096 .

ext2fs_read_block 00081000

 <4227072, 12, 8>

ext2fs_read_block 00081000

 <4227072, 20, 2>

iterate >..<

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

<DIR>       4096 ..

ext2fs_read_block 00081000

 <4227072, 24, 8>

ext2fs_read_block 00081000

 <4227072, 32, 7>

iterate >uImageb<

ext2fs read inode 131073

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <4194320, 256, 128>

         2309636 uImageb

I then did a ext2ls mmc 0:1 /boot

Marvell>> ext2ls mmc 0:1 /boot


 <2, 0, 204>

revision_level = 0x1, inode_size = 0x100

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

Iterate dir boot

ext2fs_read_block 000003e3

 <7960, 0, 8>

ext2fs_read_block 000003e3

 <7960, 8, 1>

iterate >.<

ext2fs_read_block 000003e3

 <7960, 12, 8>

ext2fs_read_block 000003e3

 <7960, 20, 2>

iterate >..<

ext2fs_read_block 000003e3

 <7960, 24, 8>

ext2fs_read_block 000003e3

 <7960, 32, 10>

iterate >lost+found<

ext2fs_read_block 000003e3

 <7960, 44, 8>

ext2fs_read_block 000003e3

 <7960, 52, 13>

iterate >rootfs.tar.gz<

ext2fs_read_block 000003e3

 <7960, 68, 8>

ext2fs_read_block 000003e3

 <7960, 76, 15>

iterate >PackageList.txt<

ext2fs_read_block 000003e3

 <7960, 92, 8>

ext2fs_read_block 000003e3

 <7960, 100, 3>

iterate >bin<

ext2fs_read_block 000003e3

 <7960, 104, 8>

ext2fs_read_block 000003e3

 <7960, 112, 4>

iterate >boot<

ext2fs read inode 393216

ext2fs read blockgroup

 <11, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <12582928, 0, 128>

ext2fs_read_block 00081000

 <4227072, 0, 8>

ext2fs_read_block 00081000

 <4227072, 8, 1>

iterate >.<

ext2fs read inode 131072

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 0

 <4194320, 0, 128>

<DIR>       4096 .

ext2fs_read_block 00081000

 <4227072, 12, 8>

ext2fs_read_block 00081000

 <4227072, 20, 2>

iterate >..<

ext2fs read inode 1

ext2fs read blockgroup

 <8, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <3864, 256, 128>

<DIR>       4096 ..

ext2fs_read_block 00081000

 <4227072, 24, 8>

ext2fs_read_block 00081000

 <4227072, 32, 7>

iterate >uImageb<

ext2fs read inode 131073

ext2fs read blockgroup

 <9, 0, 32>

ext2fs read inode blkno 0 blkoff 1

 <4194320, 256, 128>

         2309636 uImageb

Marvell>>

THIS ALSO RETURNS THE FILE UIMAGEB  which is ONLY in /opt !!!

Somehow the u-boot.bin is obtaining the contents of /opt when asking for /boot.

My brain hurts trying to follow the inode links!

BTW trying the card on the x86 box, show NO problems i.e. uImage in /boot and uImageb in /opt.

cheers

Patrick


EDIT>>>>>

Googling around, there is a lot of chatter about u-boot having problems with inode length of 256 instead of 128 bytes.

I ran tune2fs on my card and got this result:-

debsilch:/home/patrick# tune2fs -l /dev/sda1
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          43c2340e-e052-486d-8aeb-fd67117f89f8
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              491520
Block count:              1964757
Reserved block count:     98237
Free blocks:              1879310
Free inodes:              484080
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      479
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Fri Jan  1 15:23:57 2010
Last mount time:          Wed Jan  6 12:37:58 2010
Last write time:          Wed Jan  6 12:38:27 2010
Mount count:              4
Maximum mount count:      32
Last checked:             Wed Jan  6 10:08:12 2010
Check interval:           15552000 (6 months)
Next check after:         Mon Jul  5 11:08:12 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:             256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      9baf17bb-ab2c-4569-ac5a-06abfad052b4
debsilch:/home/patrick#

as you can see inode size is 256 bytes..  I don't see the same sort of error in the many other problems posted on the web about u-boot and inode size, but it is worth keeping in mind

Patrick

[pingtoo]

@superpat,

Thank you very much for patiently try out the test! ATM, I am not sure why the u-boot somehow got the inode from /opt yet, I need to study more about the code, it wasn't written in a very logical manner so I will have to read it many time to understand some of the action in the code what is trying to do. To me the code seems to be written by many different people with little comment so its going to take me some time to figure out what do to next.

I will try to see if I can come up something tonight.

pingtoo.
<Edit>
Just thought of one more testing to help find direction for debug. Please take your SD card to your PC and try to

Code:

# stat /boot
# cd /boot
# stat .

This will help to see if the '.' entry is the problem.
Thanks.

[superpat]

@pingtoo

No Problemo!

I mounted the card on /mnt/plug

Therefore I take a directory of boot  NOT /boot  (that would be my x86 system disk!)

debsilch:/mnt/plug#
debsilch:/mnt/plug# dir
bin   etc   lost+found   opt       root      selinux  tmp    var
boot  home  media   PackageList.txt  rootfs.tar.gz   srv    uImage
dev   lib   mnt      proc       sbin      sys    usr
debsilch:/mnt/plug#
debsilch:/mnt/plug#
debsilch:/mnt/plug# stat boot
  File: `boot'
  Size: 4096         Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d   Inode: 393217      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-06 12:38:20.000000000 +0000
Modify: 2010-01-01 15:51:20.000000000 +0000
Change: 2010-01-01 15:51:20.000000000 +0000
debsilch:/mnt/plug#
debsilch:/mnt/plug#
debsilch:/mnt/plug#
debsilch:/mnt/plug# cd boot
debsilch:/mnt/plug/boot# stat .
  File: `.'
  Size: 4096         Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d   Inode: 393217      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-01-06 12:38:20.000000000 +0000
Modify: 2010-01-01 15:51:20.000000000 +0000
Change: 2010-01-01 15:51:20.000000000 +0000
debsilch:/mnt/plug/boot#

and again with ls -i

debsilch:/mnt/plug# ls -i
163841 bin       11 lost+found         49153 root      466945 tmp
393217 boot  311297 media            12 rootfs.tar.gz      14 uImage
172033 dev    16385 mnt            32769 sbin      155649 usr
409601 etc   131073 opt            98305 selinux      319489 var
344065 home      13 PackageList.txt  335873 srv
294913 lib    81921 proc        303105 sys
debsilch:/mnt/plug# cd boot
debsilch:/mnt/plug/boot# ls -i
393218 uImage
debsilch:/mnt/plug/boot#

cheers

P

[pingtoo]

@superpat,

Thanks, looks like the problem is within u-boot.

[pingtoo]

Finally, found the problem

There is limit in mmc code. it can only address at most 4GB-something(which I have not exactly figure out) from beginning of a partition. So for example if you have 8GB SD, divide in to 2 partitions each 4GB, then you most likely OK with in u-boot, the mmc command set can address up to 4GB-(1 x ext2 block size) for sure, so unless you happen to have your object in that last block.

However if you divide your partitions to one greater then 4GB and the other one less then 4GB and if you wish use u-boot to access then you better put your object in the smaller partition.

All of above limitation is relate to u-boot, if you successful load your object into memory and start it, then all limitation become moot. it then all depend on you loaded program now.

I did a quick scan in the usb code, it looks like it does not have this limitation. however I stop at when the code begin SCSI command which is too much for me to study now.

Good luck

[fsieber]

There is still the "Bad Data CRC" error when booting a kernel from sd card as reported by user odoll on dec 23 2009.
I tried with uboot 3.4.27.
The issue appears when using fat and ext2 on sd card.

When loading the kernel from sd fat there comes also the error "Invalid FAT entry".

Loading the kernel from usb (fat and ext2) works with uboot 3.4.27.

In 3.4.19 loading a kernel from sd works fine.

[pingtoo]

There is still the "Bad Data CRC" error when booting a kernel from sd card as reported by user odoll on dec 23 2009.
I tried with uboot 3.4.27.
The issue appears when using fat and ext2 on sd card.

When loading the kernel from sd fat there comes also the error "Invalid FAT entry".

Loading the kernel from usb (fat and ext2) works with uboot 3.4.27.

In 3.4.19 loading a kernel from sd works fine.

I have a patched version in this thread somewhere you can download. according to odoll, my patched version fix his problem. so can you explain what is your setup and how the error occur?

[fsieber]

Thank you very much!
I finally found the patched 3.4.27: u-boot-rd88f6281Sheevaplug_400db_nand.bin-pingtoo-patch.01
It solves the problem for me to. Now I can boot a kernel from sd card.

Would it not be nice to have all the uboot binaries in the download-section of plugcomputer.org / openplug.org. With all the fixes and issues mentioned? Searching through the forum for all the uboot binaries is sometimes a difficult task.
This way I would have not been run into this issue.

Anyhow, great work!

By the way, is plugcomputer.org / openplug.org a pure community site or are marvell guys working on it (especially on the the uboot-stuff)?

Is somebody interested on a minimalistic busybox based system with only dropbear, nfs, ...? I am working on a minimalistic build script which creates such a rootfs. Having something minimalistic is sometimes better than having a full bloated debian/ubuntu/...

[pingtoo]

Thank you very much!
I finally found the patched 3.4.27: u-boot-rd88f6281Sheevaplug_400db_nand.bin-pingtoo-patch.01
It solves the problem for me to. Now I can boot a kernel from sd card.

Would it not be nice to have all the uboot binaries in the download-section of plugcomputer.org / openplug.org. With all the fixes and issues mentioned? Searching through the forum for all the uboot binaries is sometimes a difficult task.
This way I would have not been run into this issue.

Anyhow, great work!

By the way, is plugcomputer.org / openplug.org a pure community site or are marvell guys working on it (especially on the the uboot-stuff)?

Is somebody interested on a minimalistic busybox based system with only dropbear, nfs, ...? I am working on a minimalistic build script which creates such a rootfs. Having something minimalistic is sometimes better than having a full bloated debian/ubuntu/...

I don't know who run this forums. I just want to build a system that I can share with everybody who will be interested. And u-boot have a bug cause my system not working so I have to fixed it.

I have build a minimal system using busybox utilizing the build in service management system. it still not complete we can exchange idea if you want.

[rooster]

the forum is administrated by Marvell employees, I raised the issue of some content management regarding uboot (src/bin/patch) to the guys, we defenetly need to make it more easy for forum users to find the history of source/patch/bin files and some description regarding any change.

[mhtsaras]

It would be nice if the moderators/administrators of the forum and wiki, take all the above mentioned updated images of kernel, uboot, distribution and update the installer's files and configuration with all the new stuff and after testing it with the help of the members that provided them, post them online
And award the contributors/anonymous members with a generous discount on the next plugcomputer model.
Today I decided to do all the dirty work by my self and debug the all process with the help of the forum members through thiw post --> http://plugcomputer.org/plugforum/index.php?topic=1188.0 , but after reading the above post, I changed my mind and decided to wait for a bit, because this year I didn't received any present from santa ... yet!