Hi,
please use the mailing list for such questions. The memory card core
isn't documented yet, so those are good questions :)
On Mon, 2011-01-31 at 23:51 +0100, Michael Walle wrote:
> i'm looking at the memory card core atm. QEMU has a pretty complete SD card
> emulation (both SPI and SD mode). So it should not be much work to get it
> running.
Cool :) Btw, how is the upstream merge going? We might want to get a
basic version merged, and add extras later like the memory card support.
Given the time it takes for most distributions to rebuild their
packages, I think we should merge the working parts quickly. Even
without memory card support, QEMU is a very valuable tool.
The flow control for the memory card controller goes like this (same
idea for commands and data):
while (!rx_enabled or rx_buffer_full)
and (!tx_enabled or !tx_buffer_empty) {
if rx_enabled { shift_bit_into_rx_buffer() }
if tx_enabled { shift_bit_from_tx_buffer() }
pulse_memory_card_clock()
}
TX and RX buffers can hold one byte each.
By the way, I have not fully tested data TX, and, as discussed with
Lars, we might want to add hardware data CRCs to this core (they would
be a slow pain to do in software). So consider the memory card stuff as
"alpha".
> But i have some questions:
> - what is the expected sequence for sending a command?
> * MEMCARD_ENABLE = CMD_TX
> * loop 6:
> * MEMCARD_CMD = packet[i]
> * loop until MEMCARD_PENDING & CMD_TX == 0
> so i can sync to the MEMCARD_ENABLE = CMD_TX and wait for six consecutive
> writes to MEMCARD_CMD?
Yes, except that the MEMCARD_ENABLE write does not deal with command
start synchronization, only flow control - so you can skip that. There
is no way to synchronize (afaik memory card themselves do not provide
this option).
> if so, why isn't there a memcard_start_cmd_tx() before the CMD8
> memcard_send_command() (in memcard_init()) ?
When CMD8 is about to be sent, the memory card core is already in "write
enabled" mode and awaiting data into its TX buffer.
> Instead you do a memcard_send_dummy() ?
This is to give the memory card the 8 clock pulses it needs for its
internal initialization. They are pesky beasts...
> - does the memcard_receive_command() retrieve the response of the former
> command?
Yes.
> - how does the memcard_receive_command_data() works?
It waits for data to be received by the memory core on either the
command or data lines:
while(!(CSR_MEMCARD_PENDING & (MEMCARD_PENDING_CMD_RX|
MEMCARD_PENDING_DAT_RX)))
Then it fetches any received response byte on the memory card command
line:
if(CSR_MEMCARD_PENDING & MEMCARD_PENDING_CMD_RX) {
command[i++] = CSR_MEMCARD_CMD;
and acks/empties the hardware receive buffer (which would allow the core
to resume clocking the memory card and shift in the next byte - assuming
the hardware command rx buffer is empty as well):
CSR_MEMCARD_PENDING = MEMCARD_PENDING_CMD_RX;
Same with the data line:
if(CSR_MEMCARD_PENDING & MEMCARD_PENDING_DAT_RX) {
data[j++] = CSR_MEMCARD_DAT;
CSR_MEMCARD_PENDING = MEMCARD_PENDING_DAT_RX;
}
and finally loops over until the supplied data buffer is full.
S.
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com
