Date: Thu, 21 Feb 2013 07:58:40 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: The Next BeagleBone Better & Faster for Less! Message-ID: <B71C80C0-0835-403C-B196-5343AD3247FC@bsdimp.com> In-Reply-To: <1361458105.1185.19.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> On Wed, 20 Feb 2013 23:49:03 -0500 >>> George Rosamond <george@ceetonetechnology.com> wrote: >>>=20 >>>> On 02/20/13 23:27, Alie Tan wrote: >>>>> Just got a news about new Beaglebone: >>>>>=20 >>>>> http://beagleboard.org/unzipped/ >>>>=20 >>>> Wow. Although personally, I could do without the HDMI. >>>>=20 >>>> 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. >>>>=20 >>>> g >>>=20 >>> Greeting- >>>=20 >>> We need working USB support to contribute that to their site. >>>=20 >>> 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? >>=20 >> 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... >>=20 >> Warner >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B71C80C0-0835-403C-B196-5343AD3247FC>