Re: Article on the 8088 bus cycle

On 5/15/2024 7:49 PM, David Schultz wrote:

On 5/15/24 6:48 PM, BGB wrote:
 

When looking around before, I generally only found people talking about the SPI interfaces. Granted, I didn't have the official specifications (which seemed to be paywalled and not generally available otherwise). I mostly implemented stuff based on information I found on various websites.
>
>

Parts of it are/were paywalled but the interesting bit hasn't been. At least as far back as SD 1.0.
 https://www.sdcard.org/downloads/pls/
 I am not sure which one of those is the one to look at. Probably the one with the 9.1 revision level.
 

Yeah. Had found the 8.0 spec, which seemed to have some useful information.
Well, and some SDcard features which I don't really get; like apparently it is possible to route PCIe over the SDcard interface, guessing probably only some cards would support this. Like, would this be so someone could stick an SDcard in an M.2 adapter or similar?...
But, yeah, for modifications to my MMIO interface, I went with:
Adding QDATA1..QDATA3 registers, which can increase the transfer size to 32 bytes. Technically, these are using misaligned MMIO addresses, which are admittedly a route I have ended up going in a few cases (I had originally only given ~ 16B of MMIO space to the device).
Say:
   FFFF_F000E030: Status/Control
   FFFF_F000E034: DataB (8-bit transfer)
   FFFF_F000E038: DataQ (64-bit transfer)
   FFFF_F000E040: Well, PS/2 Keyboard sits here...
   FFFF_F000E050: PS/2 Mouse...
   ...
So, ended up redefining things:
   FFFF_F000E038: DataQ / DataQ0 (64 or 256 bit)
   FFFF_F000E039: DataQ1 (256-bit transfer)
   FFFF_F000E03A: DataQ2 (256-bit transfer)
   FFFF_F000E03B: DataQ3 (256-bit transfer)
The status/control register was used to check the status of SPI transfers, and to accept commands for sending data over SPI.
Using larger transfers is partly because access to the MMIO interface has a roughly 24 cycle latency, and using a bigger transfer size reduces the amount of accesses that would be spent on checking the BUSY status or writing to the Control register for bulk data.
Added bits to status/control:
   QSPI: Signals to use a QSPI transfer (vs SPI)
   READ: Signals a READ operation (vs SWAP or WRITE)
   DDR: Signals the use of DDR vs SDR
   XMIT32B: Send/Receive 32 bytes.
With a few other bits having existed:
   XMIT8B: Send/receive 8 bytes.
   XMIT: Send/Receive 1 byte.
   BUSY: SPI is still busy.
The high-order bits of the Status/Control register are used to encode a clock division relative to the base-clock.
In this case, say:
   XMITxx by itself will try to send data though CMD and DATA0 pins.
     Using DATA3 as the CS pin.
   XMITxx+READ: Will try to read data via the CMD pin;
   XMITxx+QSPI: Will send data via DATA0..DATA3;
   XMITxx+QSPI+READ: Will receive data via DATA0..DATA3;
   ...
Note that the routing of the signals to the SDcard pins is via glue logic external to the module itself (its output signals are more or less plain QSPI).
Base XMITxx would be used for SPI mode, and for writing commands.
Seems I was wrong about something before:
The combination of CMD0+CS is what selects SPI mode (for normal SD mode, the CS signal would not be asserted).
I was mistaken in thinking that it was the stream of FF bytes and then asserting CS near the end (say, the init procedure for the SDcard involving sending a large number of FF bytes at a fairly low speed, then sending some other commands and boosting the speed to the intended operating speed).