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=