From owner-freebsd-arm@freebsd.org Tue Apr 12 03:16:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1D7EB0DB2F for ; Tue, 12 Apr 2016 03:16:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B33B15D0 for ; Tue, 12 Apr 2016 03:16:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x230.google.com with SMTP id kb1so97918927igb.0 for ; Mon, 11 Apr 2016 20:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1m8QX/V3YdVBKhjdqwZUxp/Tk7wqcuEx79vAuuEd/Z4=; b=lJ0cfC8LbSAuNpiLV8qcbonm7FGXCV1uyhcRIU36Ftjx1QCpezKfvqphuZWKzjBchB Jxrr9rnVOSizwjuKGSeXRNFpF7FbVDf2nVZjJtsdw1wZ166gBm+jLtMs3M5ZYSfpHK3E Z4SJbqaPB6XAycg+90hl74giJb7wSIgn/d0hwHGdIbGo/QxSVWwZ3QPYDytcEs7h7jHG yCNXGE5feAAZIy4pT1h8zxxoP9foGnkY3bQzhoPUmHKhqunO/9S1JcD8jOGrePvrvid+ 3GghY52+4JsvxMBw6646TJifKJYgFYyh1fx1y2lu+ILRcaJFWaql+QL1/shTSlR+S69i tOOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1m8QX/V3YdVBKhjdqwZUxp/Tk7wqcuEx79vAuuEd/Z4=; b=UwK9NHxoH41OH0yGana7uRlrwsiQn53AV5FgZTISMb0OUi6S/0VWoxMCbBZx7IhtnF UL0Zv8yX0BWcbOFOyJDfUiCG01L3DLG4cb9j8pXnbxDF0LEdw5PYC1iNGhmIF61eK8Rx vNu3Cyfib9T6ShsrgInvYKatADVzY7WnZRJ8wNwzP7JDxEOchW5PcvLoQOcK0rmOAApg ituIqNP7sOSgIVBEJnrc/uhgSp8h5ww2y+PKze1xX3CW39qRYwv1eoy48j/jqSCstWlD g8Muk0J79weHn7Z7UkrvmXdpWmRMinIF6iLi8emotkjFg54zPfuU1X0HK1KccWZiFek9 V5TA== X-Gm-Message-State: AOPr4FWyHr02AxOOklCGuPOk1+Jy/mzBXcAUEr6ebQJB4mvwa8oMt/uD+rNoDWJDrniDr2QbvxAGz47efdzIzw== MIME-Version: 1.0 X-Received: by 10.50.67.113 with SMTP id m17mr1362951igt.52.1460430999620; Mon, 11 Apr 2016 20:16:39 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Mon, 11 Apr 2016 20:16:39 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1459976737.1091.289.camel@freebsd.org> References: <20160406214115.784b8a1f@zbox.lerwick.hopto.org> <1459976737.1091.289.camel@freebsd.org> Date: Mon, 11 Apr 2016 21:16:39 -0600 X-Google-Sender-Auth: sUBerNCm_7wfNSQJd1GSYYvepgQ Message-ID: Subject: Re: information on accessing nand From: Warner Losh To: Ian Lepore Cc: Craig Butler , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 03:16:40 -0000 On Wed, Apr 6, 2016 at 3:05 PM, Ian Lepore 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