I have a curious issue with one of my rev C3 Beagle Boards. It has
been working fine until the other day when I turned it on and during
Kernel boot the kernal failed to mount the root filesystem.
The 2Gb SD card is formatted as per the instructions on the Beagle
Wikis and contains a small FAT32 partion with uboot and the kernal
image (Angstrom). The second partition is EXT3 which contains the root
file system. Like I say this card and Beagleboard have been working
fine until the other day.
Having loaded the verification image onto another SD Card, and boot
using that (which uses a RAM based root filesystem), I can only see
mmcblk0p1 in /dev, and there is no mmcblk0p2.
I have tried the same two SD cards on another beagleboard and all
works fine there, so I am ruling out the SD Cards.
I was wondering if it was a hardware fault with the SD card reader but
I find that curious as SD cards are addressed serially and data is
accessed serially, so if partition 1 works fine then surely this means
the hardware is OK?
I have tried erasing the NAND on the OMAP3, re-installing the boot
loader, creating new partitions on another SD card and re-installing
the system from scratch but no joy. I have also tried other file
systems for the second partion (FAT32) and again it fails to detect
it.
I am wondering if it is some strange hardware issue - I have been
playing around with connecting SPI devices to the expansion connector,
but any software based settings in that area I have not made to the
bootloader / kernel - I am using an unmodified Angstrom console
image / bootloader (the same image used on the other Beagleboard which
is working fine). Maybe ESD damage?
Anyone got any suggestions, or has come accross this issue I would be
most grateful for advice!
Just off my mind… but are any jumper/switches in a different state? 99% this might not be the issue, but since you’ve already made sure the SD card is not the problem by booting it on other boards (which hopefully boot from the sd card instead of the internal nand or whatever), I’d suggest you also check the hardware switch configuration is same on all the boards to rule out any hw config issue. There should be something different (either the hw itself or the config or the sd card for such issues).
I will check for dry solder joints and any other possible things
alongs those lines.
I also have another theory which might explain the symptoms. SD cards
support a number of different access modes relating mainly to the
speed of access to data. I believe up to 4 data pins are used for max
speed coms. I am wondering if u-boot, which is accessing the first
partition (/dev/mmcblk01) is using a slower access mode, hence less of
the SD data pins, whereas the kernel trying to mount /dev/mmcblk0p2 is
using a higher speed mode utilising parallel data transfers, hence
more pins and perhaps one of the extra data pins is stuck high / low
for some reason. Along the same lines, the interface clock speed might
be slower for u-boot access to mmcblk0p1 whereas the clock speed is
higher on mmcblk0p2 for access from the Kernel. Only a theory at the
mo and I'll test as soon as with a scope to confirm if any of that is
true.
Mean while, any other suggestions would be appreciated.
You are right. The SD card initially starts off in the 1-bit mode and can later move up to 4-bit mode (along with a change in the frequency). Now, if the physical lines (during the 4-bit mode) have a problem, then that could be a possible explanation, but one thats remote (as that would mean either the board faced some rough weather which might be unlikely).
You can possibly check the connector for any pin bends or other physical damage.