Date: Thu, 21 Feb 2013 08:17:38 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: The Next BeagleBone Better & Faster for Less! Message-ID: <1361459858.1185.25.camel@revolution.hippie.lan> In-Reply-To: <B71C80C0-0835-403C-B196-5343AD3247FC@bsdimp.com> References: <CANuCnH9XP3Jn30EWCuZ0AmQF6MA4q4U9GUB7LU=XXZEdp7ZJ8g@mail.gmail.com> <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> <B71C80C0-0835-403C-B196-5343AD3247FC@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2013-02-21 at 07:58 -0700, Warner Losh wrote: > On Feb 21, 2013, at 7:48 AM, Ian Lepore wrote: > > > On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: > >> On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: > >> > >>> On Wed, 20 Feb 2013 23:49:03 -0500 > >>> George Rosamond <george@ceetonetechnology.com> wrote: > >>> > >>>> On 02/20/13 23:27, Alie Tan wrote: > >>>>> Just got a news about new Beaglebone: > >>>>> > >>>>> http://beagleboard.org/unzipped/ > >>>> > >>>> Wow. Although personally, I could do without the HDMI. > >>>> > >>>> It would be ideal there was a stock FBSD image for them to provide for > >>>> purchasers... as in official on their www site as an alternative to > >>>> Linux. > >>>> > >>>> g > >>> > >>> Greeting- > >>> > >>> We need working USB support to contribute that to their site. > >>> > >>> Is this new bone going to be the same as the old bone, but with video, > >>> in other words will current kernels run or will the hard core kernel > >>> folks have to rework things? > >> > >> We'll likely have to rework thing, at least if we want to run out of flash on the card. it has a new flash chip that has micron markings on it. Sure would be nice to know what, exactly, that chip is... > >> > >> Warner > > > > Unless it's a fairly old chip, or one of Micron's offerings with on-chip > > ECC, our current ecc code isn't going to handle it. I just spent weeks > > learning that the hard way. The ecc code we have checked in is a > > hamming code implementation that can correct single-bit errors, and > > modern nand chips are requiring algorithms that can correct multi-bit > > errors. Our current code also isn't ready to handle the situation where > > the SoC's nand flash controller hardware does ecc with some cooperation > > from software. > > Yes. I believe that the newest ~20nm chips require 40 bits per 1k of correction, and the current, but soon to be phased out ~25nm chips require 30 bits of correction. Only the really old 5x nm MLC parts and up through the 3x SLC parts can get bye with a 1 bit corrector. Most people use some flavor of bch code these days, not the simpler hamming code. > > I'm not aware of any NAND chips that have the ECC engine integrated into them, but that may just be due to my focus in the NAND market these days. Are you sure you don't mean ECC engines in the SoC itself, which seem to be much more common? Then again, I've been trying to avoid dealing too much with NAND Flash in open source these days... > > Warner No, I very much mean (mostly-) transparent ECC performed wholly within the nand chip. The one we just switched to (because our AT91 SoCs don't have the horsepower to do software multi-bit ecc) is MT29F4G08ABADAWP. The "mostly" part is that the hardware puts the ecc data where it wants within the spare area and if software wants to use any spare-area bytes as metadata it must work around the hardware ecc data. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1361459858.1185.25.camel>