Date: Thu, 22 Jan 2009 09:12:04 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de Cc: mav@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: Mount root from SD card? Message-ID: <20090122.091204.831807729.imp@bsdimp.com> In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20090122151340.GE50103@cicely7.cicely.de>
Bernd Walter <ticso@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090122.091204.831807729.imp>