Accessing SD cards over 4 bit MMC bus
Has anyone done it yet?
Annoyingly, the bootloader SD pins are arranged in a very unhelpful order for MMC bus (assuming we connect DAT1 and DAT2 to P56 and P57). Luckily, I think smartpins and the MERGEW op can make it work, anyways. Assuming 250MHz P2 clock, there's 5 cycles available per high-speed SD clock (50 MHz). There's no way to read 4 arbitrary pins and add them to a long in that time. But if we read 8 bits at a time with smartpins, we have 40 cycles to read the 4 smartpins and arrange the received data in a sensible way. I'm thinking this'd work (or something very similar, anyways)
'' The 4 data pins must be in 8 bit synchronous receive mode '' SE1 must be set to the rising edge of any of them '' Also need to somehow generate the clock pulses. rep @.rdlp,#128 waitse1 rdpin tmp,pin_dat3 rolbyte lbuf,tmp,#3 rdpin tmp,pin_dat2 rolbyte lbuf,tmp,#3 rdpin tmp,pin_dat1 rolbyte lbuf,tmp,#3 rdpin tmp,pin_dat0 rolbyte lbuf,tmp,#3 mergeb lbuf wflong lbuf .rdlp
The next problem is generating the 50 MHz clock. Transitions mode would be ideal, but that can only do even periods, so it can only generate 50 MHz when sysclock = 50MHz*2*N. Most SD cards these days support UHS-1 modes though, so I'd assume they will accept slightly more than 50 MHz in normal modes? Would have to be tested. Not sure if 62.5 MHz is OK (250 MHz / (2*2)). The next step down would be 41.6 MHz. Still much faster than anything in SPI mode.
Also, the CMD pin needs to be handled somehow. I don't think there's anything happening on that line during transfers unless the host sends a command first, so fine I guess?
Another thing: What is CS in SPI mode becomes DAT3, so what about that flash that hangs off that pin? I guess it can be disabled using the DIP switches... OTOH, what's the point of using the boot SD pins when you're going to boot from flash? So it's fine I guess?