Trouble using ext2ls/ext2load

[theRealBigP]

I'm using kwonsk's uBoot modifications in order to try and get my kernel to boot from an SD card. I have that uBoot version installed successfully, and mmcinit works just fine, but I can't figure out how to use the ext2ls and ext2load commands. Both of them simply display usage information, regardless of what options I pass. Are those commands just placeholders that aren't functional yet? How can I get ext2ls to display the contents of a folder on my SD card, which appears as /dev/mmcblk0p1 when I have booted Ubuntu?

[theRealBigP]

Ok, I got a little farther with ext2ls. The built-in help doesn't tell you all the options that need to be passed in, but searching around revealed the syntax to be something similar to:

ext2ls mmc 0:1 /

That command lists all the files in the root of my SD card. Now I'm just having trouble figuring out the correct args for ext2load.

[theRealBigP]

I finally figured this out. Assuming you have a single ext2 partition on your SD card, and have placed the kernel image in the root of that partition, the following sequence of commands from the uBoot prompt will load the kernel image into memory and then boot it:

Code:

mmcinit
ext2load mmc 0:1 0x2000000/uImage.sheeva.040309
bootm 0x2000000

Hope this helps someone else, and thanks to kwonsk for the patches to uBoot to make this possible.

[restamp]

Can someone explain how the ext2ls and ext2load commands can be used to access a partition other than the first one on an SDcard?  For instance, "ext2ls mmc 0 /" and "ext2ls mmc 0:1 /" both work for listing the root directory on the first partition, but I cannot figure out a way to list the 2nd partition, /dev/mmcblk0p2, also an ext2 FS.  I've tried "ext2ls mmc 0:2 /" and several other permutations without success.  Is it a bug that the ext2ls and ext2load commands only appear to work on the first partition, or a misunderstanding on my part?

Also, when trying to access a uImage on the first partition, I note that this file, along with several root-level directories (/bin, /user, /home, etc.) are reported by ext2ls to be of zero length, and "ext2load  mmc 0 0x800000 /boot/uImage" reports 0 bytes read.  Would this be because I defaulted this partition to 256-byte Inodes and be corrected if I remade the root FS with 128-byte Inodes?  (I don't particularly want to re-do this on speculation.)

Thanks in advance.

[rooster]

you can for example format your SD with two ext2 partitions and access a uImage that is place in the first partition in /boot directory.
To read the uImage content to RAM do the following: mmcinit; ext2load mmc 0:1 0x800000 /boot/uImage.
To access the second partition change the 0:1 to 0:2, and access the files you want.

The current uboot support dynamic inode size, so you should not have any trouble accessing those files.

I noticed that with several SDHC cards I had to add to the bootargs_root (uboot environment) the rootdelay=5, it is needed if you want to use uImage and rootfs from the SD since some cards tend to start slow and kernel does not recognize them on time.

Be sure to use latest kernel (that includes all SD patches), I used 2.6.30.2 with no problems mounting uImage and rootfs from several SDHC cards

[restamp]

Rooster, thanks for your help.  Is the "current" Uboot the one that is installed by the Alpha-6 installer [ U-Boot 1.1.4 (May 13 2009 - 13:10:52) Marvell version: 3.4.16 ], or is there a newer one?

I do not appear to be able to use "0:2" to access the second partition here, although I can run fsck.ext2 on it and it mounts fine under Linux.

In addition, some directories and files on the 1st partition appear to be zero length to the Uboot (and unfortunately, uImage is among them), although they clearly are not when running Linux.  I think this is the root cause for my not being able to read in the uImage from the first partition.  The ext2load succeeds in reading zero bytes!

Any ideas?  The only oddity with uImage is that I have it hard linked to several places in an effort to diagnose this problem (but that shouldn't be a problem, should it)?

[rooster]

The uboot version (3.4.16) the plug ships supports dynamic inode size.

What Kernel version are you using? does it include SD patches from http://sheeva.with-linux.com/sheeva/2.6.30.2/patches/mvsdio-1-2.6.30.patch and http://sheeva.with-linux.com/sheeva/2.6.30.2/patches/mvsdio-2.patch?

If you use kernel from http://sheeva.with-linux.com/sheeva/ it already includes these two patches.

Have you tried another SD card?

Have you been able to see all files from Linux?

[restamp]

Rooster,
I'm currently using the software installed by the Alpha-6 installer, which includes the Uboot mentioned here, and the 2.6.30-rc6 kernel.

I'm not sure why the kernel would be important, as the problem occurs before the kernel is loaded.

I have not tried another SDcard.  (Actually, I don't have any other cards handy.)  However, the card in question has been used for the past month under the original and rc6 kernels w/o exhibiting any problems.

My desire is to eventually upgrade to the 2.6.30.2 kernel, but I'd like to be able to figure out how to make it boot completely off the SDcard so that I have a fall back path if something doesn't work right.

Here is the output of some manually entered commands from Uboot:

Code:

U-Boot 1.1.4 (May 13 2009 - 13:10:52) Marvell version: 3.4.16

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

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
Flash:  0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
Marvell>> mmcinit
SDHC found. Card desciption is:
Manufacturer:       0x1d, OEM "AD"
Product name:       "SD   ", revision 0.0
Serial number:      3003129443
Manufacturing date: 5/2009
CRC:                0x00, b0 = 0
Marvell>> ext2ls mmc 0:1 /
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<DIR>          0 bin
<DIR>       4096 dev
<DIR>       4096 etc
<DIR>       4096 lib
<DIR>       4096 mnt
<DIR>       4096 opt
<DIR>       4096 srv
<DIR>       4096 tmp
<DIR>       4096 sys
<DIR>       4096 var
<DIR>          0 usr
<DIR>       4096 boot
<DIR>          0 home
<DIR>          0 proc
<DIR>       4096 sbin
<DIR>       4096 root
<DIR>       4096 media
<DIR>       4096 selinux
<DIR>       4096 hd
               0 uImage
Marvell>> ext2ls mmc 0:1 /boot
<DIR>       4096 .
<DIR>       4096 ..
               0 uImage
               0 uImage-2.6.30-rc6
Marvell>> ext2ls mmc 0:2
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:2 **
Marvell>> ext2load mmc 0:1 0x800000 /uImage

0 bytes read
Marvell>> 

Note the zero lengths on some of the directories in the ext2ls listing, and the uImage.  Note that the ext2load command doesn't fail -- it just reads in zero bytes.  Also note that the "0:2" attempt fails, although once I boot Linux, I can access this partition w/o problems.

Anyway, that's where I stand.  I'm hoping someone may see something I dont.

Addendum: I just satisfied myself that I was able to change the bootargs_root parameter to "root=/dev/mmcblk0p2" and boot Linux with the root FS being the second partition.  I really believe the inability to access the second partition with Uboot is entirely a Uboot issue.  (And, this doesn't address the zero-length file issue at all.)

[restamp]

Success!  After much fooling around, I tried copying the uImage from /boot to /.  (Previously, I had hard-linked the files.)  I was trying to see if a link count of something other than '1' was the problem.  After doing this, ext2ls started listing the uImage with its true filesize, so I tried an ext2load, and that worked!  Further investigation proved that the link count had nothing to do with the problem.  Thus, it appears to me that the Uboot I am using has two problems in dealing with ext2 file systems and mmc devices:

1.  While most files on the ext2 filesystem are accessible from the Uboot, for some reason a few files (and directories) are not.  An ext2ls command shows the inaccessible files and directories as being of zero length in its listing, even though the Unix kernel itself has no problem accessing them.

2. For some reason, the ext2ls and ext2load commands are only capable of accessing the first partition on an SDcard. [ If someone has a Plug where these commands can successfully address a deeper partition, please post it.  I'd like to know about it. ]

Anyway, thanks to everyone, and especially rooster, who provided suggestions.  I'm checking out the 2.6.30.2 load on my Plug as I type this!

[birdman]

2. For some reason, the ext2ls and ext2load commands are only capable of accessing the first partition on an SDcard.

I'm still waiting for my Plug to be sent, so can't test anything.
But - I can make a random guess at a possibility.
When you say "second partition", do you mean that, or do you mean "another partition".  Is this second partition really (e.g.) /dev/sda2, or is it /dev/sda5, which would be a logical partition?

[restamp]

Hi Birdman,
Interesting observation, but I don't think this is the problem.

First, I am referring to an SDcard, rather than a hard drive, so the devices associated with the partitions in /dev are not /dev/sd* devices.  But, yes, I am speaking of primary partitions, and not logical ones.  Here is an "fdisk -l" of my SDcard:

Code:

root@sheeva:~# fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 16.2 GB, 16288579584 bytes
79 heads, 18 sectors/track, 22372 cylinders
Units = cylinders of 1422 * 512 = 728064 bytes
Disk identifier: 0xdaa7c368

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               6       10502     7463367   83  Linux
/dev/mmcblk0p2           10503       20999     7463367   83  Linux
/dev/mmcblk0p3           21000       22372      976203   83  Linux
root@sheeva:~#

All partitions are primary.  The first two have ext2 file systems on them.  The third is used for swap.