[meta-ti] [PATCH] u-boot 2011.12rc1: OMAP MMC: Add delay before waiting for status

[Andreas Müller]

On Tuesday, December 27, 2011 11:32:26 PM Tom Rini wrote:
> On Tue, Dec 27, 2011 at 12:13 PM, Peter A. Bigot <bigotp at acm.org> wrote:
> > From: "Peter A. Bigot" <bigotp at acm.org>
> > 
> > Pending upstream patch from http://patchwork.ozlabs.org/patch/132795/ is
> > required to successfully boot on xM.
> > 
> > Signed-off-by: Peter A. Bigot <bigotp at acm.org>
> 
> I don't see the harm here so:
> 
> Acked-by: Tom Rini <tom.rini at gmail.com>
> 
> But I need to talk with Andreas a bit and see what's going on here as
> I hadn't seen that problem here before.
Some more background on this patch:

For my two overos board revision 2 I got

| reading uImage
| mmc_send_cmd: timedout waiting for stat!
|
| 2860468 bytes read

but the loaded kernel worked without issues. To invesigate, I added a message in 
drivers/mmc/omap_hsmmc.c / mmc_send_cmd():

	while (readl(&mmc_base->stat)) {
		if (get_timer(0) - start > MAX_RETRY_MS) {
			printf("%s: timedout waiting for stat!\n", __func__);
-->			printf("cmd->cmdidx: %u\n", cmd->cmdidx);
			return TIMEOUT;
		}
	}

This lead to

| cmd->cmdidx: 13

which is found in include/mmc.h:

| #define MMC_CMD_SEND_STATUS 13. 

This cmdidx is only set once in drivers/mmc/mmc.c / mmc_send_status(). On all 
calls of mmc_send_status I added (see attachment)

printf("mmc_send_status called from %s\n", __func__);

and got:

| reading uImage
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| mmc_send_status called from mmc_read_blocks
| 
| 3018844 bytes read

This showed me (I recreated this here with a different kernel):
1. In my case mmc_send_status is called only from mmc_read_blocks and < 10 times
2. The error message disappeared!!

So I added the delay as you see in the patch. I started with a delay of 10ms and 
reduced it to minimum of 1us and the error did not occure anymore.

Maybe the problem is depending on the SDcard type? At the moment I cannot tell 
which card type I used because it is at the office. It seems Peter had same 
issues: Which card type do you use?

Happy new year

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-test-printf.patch
Type: text/x-patch
Size: 1552 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20120102/7f2698d0/attachment.bin>