Mount root from SD card?

[Bernd Walter]

On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote:
> Bernd Walter wrote:
> >Yes - and this is broken in the Atmel design.
> >This is not the only nasty bug that Atmel has left int he chip.
> >You need to issue the STOP command at the absolut right timing, which
> >is more or less impossible.
> >The design puts every 32bit word in a receive register, which has a small
> >fifo.
> >You can setup a DMA enginge to pull the words from the register into RAM.
> >Now what happens is that if you issue the STOP too late it starts reading
> >the next block and then stops - the card can stop at every location, so
> >there is no problem about this, but now you have the first words in the
> >receive fifo.
> >The DMA doesn't work anymore, because it was setup with a limited number
> >of words to pull, so the additional words are kept in the register.
> >Once you start reading the next block and setup the DMA it pulls the
> >stuck words first.
> >It that case it looks as if the timing is one word too late therefor
> >you get 4 additonal bytes after each transaction.
> >It shouldn't be a problem to read the receive register without data in
> >it, so 4 or 5 dummy reads befor DMA setup should be enough.
> >IIRC the fifo can only hold up to 3 words.
> 
> Looks realistic. Just needed somebody with hardware to investigate it.

I unfortunately don't have the time right now.

> But even if current problem seems to be alike, the reasons are probably 
> different. At this time, mmc/mmcsd layers are strictly instructed to not 
> issue multi block operations to the at91 controller. There is something 
> different pollutes the buffer.

That's the point why I was not sure if it applies here.
Is there anything else issued which needs a STOP?
I'm really a bit out of SD card command handling...

> But may be cleaning that FIFO before starting transfer could become 
> universal solution.

Probably - especially because multiblock operations are a massive
speed factor, but it would still be good to know why it happens here.

With multiblock writing we don't have this problem, because we have
to supply the data and there is no reson to supply more than we need to
send.
The reason why we don't allow multiblock writes with this controller is
just because we need a temporary buffer to reorder the bytes, which is
fixed allocated to one block - the MCI in the RM9200 uses the wrong
byte order - sigh...
Would be good to use a larger buffer some day to speed up writing.
Especially with writing multiblock would be a major enhancement.

As another point:
Is it possible to support SHDC with mci some day, or is there a special
hardware requirement for SDHC?

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.