Re: [Qemu-devel] [PATCH v2 2/3] hw/sd: model a power-up delay, as a workaround for an EDK2 bug

[Andrew Baumann]

> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Sunday, 20 December 2015 14:58
> On Wed, Dec 16, 2015 at 11:02 AM, Andrew Baumann
> <address@hidden> wrote:
> > The SD spec for ACMD41 says that a zero argument is an "inquiry"
> > ACMD41, which does not start initialisation and is used only for
> > retrieving the OCR. However, Tianocore EDK2 (UEFI) has a bug [1]: it
> > first sends an inquiry (zero) ACMD41. If that first request returns an
> > OCR value with the power up bit (0x80000000) set, it assumes the card
> > is ready and continues, leaving the card in the wrong state. (My
> > assumption is that this works on hardware, because no real card is
> > immediately powered up upon reset.)
> >
> > This change models a delay of 0.5ms from the first ACMD41 to the power
> > being up. However, it also immediately sets the power on upon seeing a
> > non-zero (non-enquiry) ACMD41. This speeds up UEFI boot; it should
> > also account for guests that simply delay after card reset and then
> > issue an ACMD41 that they expect will succeed.
[...]
> Can this be done in a non-rPI specific way by just kicking off the
> timer on card reset?

No :( I tried that first, but there is no value for the timeout that works 
reliably and isn't huge. UEFI doesn't reset the card itself (it relies on the 
hardware reset), and there can be a large/variable delay after power on before 
its gets to the SD init (particularly for debug builds, which do lots of 
printing to the serial port).

BTW, this is generic to UEFI; I don't believe it's Pi-specific.

Andrew