Date: Tue, 18 Mar 2014 08:12:43 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@FreeBSD.org> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? Message-ID: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> In-Reply-To: <CAJ-VmomM=8M420-LC0z1CoZcz%2BjRBKx4n31ebtbfWG8_xF4Npw@mail.gmail.com> References: <CAJ-VmonpUsvXFHMCyH--3S4AEocTjhESCyjp9UmT-w5GyuZmvw@mail.gmail.com> <CAJ-VmomM=8M420-LC0z1CoZcz%2BjRBKx4n31ebtbfWG8_xF4Npw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 18, 2014, at 6:55 AM, Adrian Chadd <adrian@FreeBSD.org> wrote: > .. wow. So, this gets even more problematic. >=20 > 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=92s 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=92s not the worst of it. that=92s child=92s play, really. > So, at first glance: >=20 > * 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 =91low level=92 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=92ve also been looking towards this area as well, given my recent NAND history. In fact, I=92ve 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@freebsd.org> wrote: >> Hiya, >>=20 >> 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. >>=20 >> 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. >>=20 >> So, what gives? >>=20 >>=20 >> -a > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to = "freebsd-embedded-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5BF1217D-6423-443B-A3AB-1722CDDDAD74>