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

[Peter Crosthwaite]

On Mon, Dec 21, 2015 at 1:04 PM, Andrew Baumann
<address@hidden> wrote:
>> 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.
>

Ok fair enough,

This way works and handles pretty much every case. There is one more
review comment RE the VMSD ill make on original mail.

Regards,
Peter

> Andrew