System sometimes stuck at "Waiting for root device /dev/mmcblk0p2... " during boot

Hi Sean,

Is your card detect pin connected?

Best regards,
Miroslav

Hi Sean.

You may find the discussion in http://e2e.ti.com/support/arm/sitara_arm/f/791/p/261831/916178.aspx#916178 useful.

Regards,

    Steve

Yes CD is connected, and I get the problem both when I specify the CD field as the correct GPIO or disable it with -EINVAL.  I am using ext4 mounting an ext3 partition.

Hi Sean.

-EINVAL doesn't disable CD.  Rather, it indicates that something other than GPIO is used for CD (ie, doesn't apply to your situation).  As Mario indicated in the other thread, am335x_mmc[0].nonremovable = true disables CD.

If you add debug printks to the detect function in drivers/mmc/host/omap_hsmmc.c, you'll be able to see what the kernel sees.

Regards,

    Steve

Thanks Steve,

Today I experimented with setting nonremovable to true and specifying the GPIO for the CD signal.  I monitored the CD signal on the scope and it looks fine (inverse logic).  I tried adding debug printks to omap_hsmmc_card_detect and omap_hsmmc_get_cover_state in omap_hsmmc.c but it looks like in my case they are never reached.  Note that on my hardware I have 10K pullup resistors on all the lines to the SD card, as well as pull-ups defined in the pinmux, not sure if that's a problem?

I also turned up the debug level in the MMC code, when I get the boot problem I get a continuous stream of

[  132.344909] driver_probe_done: probe_count = 0
[  132.454895] driver_probe_done: probe_count = 0
[  132.564910] driver_probe_done: probe_count = 0
[  132.674926] driver_probe_done: probe_count = 0
[  132.784912] driver_probe_done: probe_count = 0

messages.

Hi Sean.

The driver_probe_done messages are from init/do_mounts -- a symptom of it waiting for the root device to become available.

I doubt the combination of the resistor and the mux pull-up is a problem.  The EVM board does the same thing except that it uses a 470k resistor.  A short to ground within the connector should have no problem overcoming both.

All I can suggest is to add some reading of the GPIO registers in some appropriate init code (at mount wait?) to see what the processor believes is the state of the line and the GPIO configuration.  And likely read the associated control register to verify that the mux settings didn't get changed by another driver after the omap_hsmmc_gpio_init() code ran.

Regards,

    Steve

The card detect signal is being read reliably and I've also seen the problem when setting the MMC0 structure to not removable.

What I do see is that when the boot hangs it is always preceded by two SD card related messages:

[    3.781463] mmc0: unrecognised SCR structure version 8
[    3.790832] mmc0: error -22 whilst initialising SD card

This indicates to me that there's some type of corruption reading the card.  I've tried multiple cards, fscked the file system on each, and tried different boards but the problem still remains.  Most of the time the board boots OK but sometimes it will display the above log messages and hang.  How can I get this working reliably?

I did some further testing and the problem stems from the mmc_decode_scr function in drivers/mmc/core/sd.c in the kernel.  The code is reading scr_struct as non zero sometimes, which is causing the function below to return -EINVAL.  The actual value returned is not consistent when it's non zero either.  If I remove this check and let the system continue to boot it still boots and runs successfully.  But I would like to know why the SCR on the SD card is sometimes returning non zero.

        scr_struct = UNSTUFF_BITS(resp, 60, 4);
        if (scr_struct != 0) {
                pr_err("%s: unrecognised SCR structure version %d\n",
                        mmc_hostname(card->host), scr_struct);
                return -EINVAL;
        }