Mount root from SD card?

[M. Warner Losh]

In message: <20090122151340.GE50103 at cicely7.cicely.de>
            Bernd Walter <ticso at cicely7.cicely.de> writes:
: 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.

Yes.  We could have a larger buffer, but we still need the reset the
fifo after each transfer hack.  I tried to implement it long ago, but
it failed to work reliably...

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

It should be, in theory, possible.  sdio is a different matter due to
timing issues, but SDHC should be possible...

Warner