Hi Philippe, On Mon, Feb 8, 2021 at 9:08 PM Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > > On 1/30/21 11:20 AM, Bin Meng wrote: > > Hi Philippe, > > > > On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé <f4...@amsat.org> > > wrote: > >> > >> Hi Bin, > >> > >> On 1/29/21 9:51 AM, Bin Meng wrote: > >>> From: Bin Meng <bin.m...@windriver.com> > >>> > >>> Unlike SD mode, when SD card is working in SPI mode, the argument > >>> of CMD13 is stuff bits. Hence we should bypass the RCA check. > >> > >> Is this for detecting events by polling? From spec v8: > >> > >> 5.7.5 Event Indication Method > >> 5.7.5.1 FX_EVENT (Bit06 of Card Status) > >> > >> An event indication method is introduced from Version 4.20. > >> Card may use Bit06 of R1 (R1b) response of any SD command > >> to indicate event generation. > >> > >> F.2 Concept of Event Detection Method > >> F.2.2 Host Implementation to use Event Detection Method > >> > > > > I think you looked at the wrong place. See spec v8 > > > > chapter 7.3.1.3 Detailed Command Description > > > > "The card shall ignore stuff bits and reserved bits in an argument" > > > > and Table 7-3 Commands and Arguments > > > > CMD13 Argument [31:0] stuff bits > > Indeed. Adding this information in the commit description makes > things obvious ;)
I thought that's already obvious. If you search for "stuff bits" or "CMD13" in the spec, you will get the information. > > The SPI responses are not well implemented, in this case (CMD13) > it is incorrect, we should return a 2-byte R2. Your patch > correctly skip the RCA check, but we still invalid data. This is already handled in ssi-sd.c in SPI mode. As for the SD mode, that should be a separate patch instead of mixing two fixes into one. Regards, Bin
