On Mon, Dec 21, 2015 at 1:04 PM, Andrew Baumann <andrew.baum...@microsoft.com> wrote: >> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] >> Sent: Sunday, 20 December 2015 14:58 >> On Wed, Dec 16, 2015 at 11:02 AM, Andrew Baumann >> <andrew.baum...@microsoft.com> 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
