nand controller - how should one handle controllers that want the command+address bits together?

[Warner Losh]

On Mar 18, 2014, at 6:55 AM, Adrian Chadd <adrian at FreeBSD.org> wrote:

> .. wow. So, this gets even more problematic.
> 
> The AR934x NAND controller does DMA for the read/program phases as
> well as command results (eg READID.) Now,  I can likely easily hack
> around it for simple commands like READID by overloading the
> nfc_start_command() method.

Quite ugly, yes.

> For the read phase, I'd have to do a copy out of the buffer into the
> buffer supplied to the NAND bus code. Cool, that's just highly
> inefficient (why aren't we doing buffer IO here again? Bueller?) but
> that's a different story.

Since most of this stuff was bit-banged or PIOd out, who cares if there’s
a copy...

> For the write phase though, it's totally horrible. I'd have to buffer
> the command byte(s), the address byte(s) and the NAND bus write (which
> would copy it into the outgoing buffer), then issue it all at once.

That’s not the worst of it. that’s child’s play, really.

> So, at first glance:
> 
> * why aren't these (command; address; address; start) method runs just
> wrapped up into a command method that looks vaguely like (command,
> command2, row, column, id, buffer) and let the controller code either
> unravel it into serialised writes out, or in the case of the ar934x
> NAND controller, use all that information to setup a DMA transfer;

Because the state machines needed for different NAND types more or
less require the ‘low level’ interface that we have today. The different
phases in setting up a transaction vary somewhat between the different
types of NAND, and we have no real knowledge of that in the NAND layer
today. It was written 4 years ago when most controllers on the market
did little more than bit-bang and/or module the signals to the NAND since
the interfaces at the time were little more than fancy memory mapped
memory controllers.

> * .. and for reads/writes, the buffer is supplied here, so they can
> also be used to setup the DMA transfer, else they're just serialised
> out via port banging for dumber NAND controller latches.

Yes.

> I really want to try and bring this flash chip up (even without
> hardware ECC) but I'm kinda worried that in order to do this cleanly
> I'm going to have to overhaul nandbus/nfc and a couple of NAND
> controllers I don't have (and currently don't want) hardware for.

I’ve also been looking towards this area as well, given my recent
NAND history. In fact, I’ve been putting together a talk for BSDcan
on what needs to be done to make the NAND layer sane, cool and
groovy.

> So, any help/ideas?

You already layer it out: You have to be ugly.

BTW specifically, what NAND are you talking to?

Warner


> On 18 March 2014 04:35, Adrian Chadd <adrian at freebsd.org> wrote:
>> Hiya,
>> 
>> I've got the atheros ar934x nand controller bits looking like they're
>> working on freebsd-head enough to send/receive a READID command with
>> an address of 0x0. However, the NAND controller sends commands with
>> the cmd and address phases as part of the command, rather than calling
>> send_command / send_address methods called multiple times.
>> 
>> It seems like our nandbus and nand controller layer is a very thin
>> shim over what the NAND control messages look like, rather than some
>> higher level 'thing' that allows for slightly more intelligent (read:
>> DMA/ECC capable) hardware.
>> 
>> So, what gives?
>> 
>> 
>> -a
> _______________________________________________
> freebsd-embedded at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded
> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe at freebsd.org"