Date: Mon, 11 Apr 2016 21:16:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Craig Butler <craig001@lerwick.hopto.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: information on accessing nand Message-ID: <CANCZdfr0_MvAhb=PgGBpN1mNFufvq7tb7xtWSn9rrGdux_929w@mail.gmail.com> In-Reply-To: <1459976737.1091.289.camel@freebsd.org> References: <20160406214115.784b8a1f@zbox.lerwick.hopto.org> <1459976737.1091.289.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 6, 2016 at 3:05 PM, Ian Lepore <ian@freebsd.org> wrote: > On Wed, 2016-04-06 at 21:41 +0100, Craig Butler wrote: > > Hello List > > > > Is there a HOWTO or some instructions/black magic for adding new > > definitions and drivers for accessing currently unsupported nand ?? > > > > So far I *think* I need to; > > - define the nand in the board dts definitions > > - code a nfc_ (omap2??) driver > > - set kernel configs with option nandfs and WITH_NAND="YES" > > - cross fingers > > > > Have I missed anything ? > > > > Kind Regards > > > > You should be aware before you get too far into this that there is lots > of stuff in freebsd related to nand, and most of it doesn't work. The > driver framework is completely tied to 1-bit hamming code ECC, which is > only used by ancient small chips, nothing modern. There's some work to make things more modern, but it's quite immature still... > If you get past that > (say, by using chips with builtin hardware ECC that appear to just > never get errors), you quickly discover that the nandfs code is slow > and buggy. Slow like it can lock up the system for seconds at a time NANDFS isn't so slow. On SSDs it's quite fast. This bit is due to rather long DELAYs that are hard coded and no polling of the proper lines nor any provision for interrupts. Annoying, and a flaw, to be true, but not in the NANDFS layer :) > Buggy like it corrupts data and there's no way to recover. > That's NANDFS's fault. It gets the locking wrong. It works for NetBSD, where the code originated, but it drops locks in a way that on FreeBSD causes guaranteed corruption when there's vnode pressure. These can be fixed, but there's a number of ripples this causes. You forgot the bit where nandfs constantly does garbage collection, even when it doesn't make sense, so you wind up with a fair amount of write amplification that wears out the NAND bits. Oh, and no DMA support, no hardware ECC support, no support for ONFI parts, or JEDEC parts. No good support for different C/S lines, so multi-die parts are hard to deal with. None of the faster transfer mode switching is supported. Plus most of the modern chips that have cool new NAND controller hardware don't document it. The manual chapters tend to be bare recitation of registers, often with the specific bits omitted. Different ECC technology is vague at best. And the latest chips that aren't 3D require sophisticated LDPC error correction and crazy multi-pass reading to recover the data. MLC and TLC parts also have slightly different command sets than the SLC that we support. 3D adds its own wrinkles as well. I'd love to modernize the FreeBSD NAND stack, but it would be a fulltime job for months and months for a couple of people at least. And even then the sophisticated bits likely wouldn't be implemented even still. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr0_MvAhb=PgGBpN1mNFufvq7tb7xtWSn9rrGdux_929w>