From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 16 14:38:25 2010 Return-Path: <owner-freebsd-embedded@FreeBSD.ORG> Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC68106568D for <embedded@freebsd.org>; Tue, 16 Mar 2010 14:38:25 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE4A28FC12 for <embedded@freebsd.org>; Tue, 16 Mar 2010 14:38:24 +0000 (UTC) Received: by pwj4 with SMTP id 4so6842pwj.13 for <embedded@freebsd.org>; Tue, 16 Mar 2010 07:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=5pIAfWwG6IAlOyDmWcVeFujQrhpUO0EBGQ7PuAi/dLc=; b=YrbY+9jr3tViLLihsYasQ2uNZarKfmSqoBMSHRan2bmRIdlCUQna6u1Msp4DK9Pguy vmxfNID9wK864vZpW63ggC0sFN+ROtgBlt02ojopdw5MO++0m1usLk16AOfoWNJtJGjt NUBmO3RkRqREQJXXHz0bA/jfM8lE/HU4T+Lhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=IzFFJEOOfce2XMRHbU5c7ovfrwE5jF6dJhRCHmy6zHs+LGUOo537kRJzm3oe5wdTX8 iWxh+IBjR7sMO0uOPu98P/4ilHq1v0ABP/d3VS6jHWfyusswwBZTAMAp62YWiUmYKgPr H1MNdd83VF5HUXdcv1hQpFVzC7IkWXSvW3p6Q= Received: by 10.140.56.17 with SMTP id e17mr35939rva.98.1268750303104; Tue, 16 Mar 2010 07:38:23 -0700 (PDT) Received: from [192.168.0.86] ([187.39.15.241]) by mx.google.com with ESMTPS id 4sm2077905ywi.6.2010.03.16.07.38.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 07:38:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) From: Luiz Otavio O Souza <loos.br@gmail.com> In-Reply-To: <20100316101044.0401295e@fubar.geek.nz> Date: Tue, 16 Mar 2010 11:38:18 -0300 Message-Id: <0410ED4A-2086-470D-A184-2CD95644700E@gmail.com> References: <0AE04EFA-A3EB-4939-BD81-607C00355B67@semihalf.com> <20100314165825.121d346b@fubar.geek.nz> <CC419602-A9E8-4FE2-A5A5-0BFBD8240EDD@gmail.com> <4B9E1697.9090602@semihalf.com> <20100316101044.0401295e@fubar.geek.nz> To: Andrew Turner <andrew@fubar.geek.nz> X-Mailer: Apple Mail (2.1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: embedded@freebsd.org Subject: Re: NAND Flash Framework for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems <freebsd-embedded.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-embedded>, <mailto:freebsd-embedded-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-embedded> List-Post: <mailto:freebsd-embedded@freebsd.org> List-Help: <mailto:freebsd-embedded-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-embedded>, <mailto:freebsd-embedded-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 16 Mar 2010 14:38:25 -0000 On Mar 15, 2010, at 10:10 PM, Andrew Turner wrote: >>>>=20 >>>> Ideas: >>>> - Can we move ecc and bbt handling into GEOM? This will allow us to >>>> bypass them when required. >>>=20 >>> This is a mandatory feature (disable ecc and may be the bbt checks) >>> if you need to deal with some kind of unknown nand FS or unknown >>> nand oob layout (like make a backup of your unknown nand data >>> before erase it). >>=20 >> Ok, I didn't know that disabling ECC and BBT is so important. Let me >> think about moving it to geom layer. >=20 > It is also important for filesystems that have their own ECC handling > code, e.g. YAFFS expects to manage the OOB it's self including the = ECC. > I'm not sure how it expects to handle the BBT. >=20 Another detail on ECC check... you don't need to save or check the ecc = for the first block, it must never fail. If your first block is bad, you = can't boot from NAND (the bootloader will be probably unreadable). YAFFS1 only support devices with 512/16 bytes layout and it do all the = ecc and bad block management (using the default layout for this kind of = chip). YAFFS2 works with all types of chips (different layouts) and, basically, = it relies on the driver ecc and bad block management. But it is not as simple as that, as you can select the use of inband = tags (the yaffs metadata which should be on free bytes of oob can be = saved 'inband') and a few other tricks (like mkyaffsimg which generate = the oob data and looks like ignore the bad block management). Luiz=