From owner-freebsd-embedded@FreeBSD.ORG Mon Feb 25 17:11:09 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A91C416A403; Mon, 25 Feb 2008 17:11:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.83]) by mx1.freebsd.org (Postfix) with ESMTP id 97F8213C4EF; Mon, 25 Feb 2008 17:11:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout020/MantshX 4.0) with ESMTP id m1PHB0lw025764; Mon, 25 Feb 2008 09:11:00 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id m1PHAq1h001520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2008 09:10:53 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Andrew Duane In-Reply-To: <0FCFCF6165E968449991746EB91D614D010318EC@antipi.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 25 Feb 2008 09:10:52 -0800 References: <47C01F1B.3020107@FreeBSD.org> <47C03036.4040409@FreeBSD.org> <9C903216-6C19-4D6F-80D2-27C161845567@mac.com> <20080223.093044.282837835.imp@bsdimp.com> <33A08235-8501-432E-BB89-0F4A44D7F39A@mac.com> <0FCFCF6165E968449991746EB91D614D010318EC@antipi.jnpr.net> X-Mailer: Apple Mail (2.919.2) Cc: bms@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: /dev/cfi NOR flash driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 17:11:09 -0000 On Feb 25, 2008, at 6:30 AM, Andrew Duane wrote: > Havig worked on projects with both NOR and NAND before, there isn't > much > value to be had in combining them. The operations and control flows > just > aren't close enough to make it worthwhile. I didn't mean to write a signle driver to handle both, but rather a single infratsructure in which both live. > Also, what were you referring to with "eraseblock" operation? The > concept of eraseblocks is critical, as when a page is written, an > entire > eraseblock needs to be "allocated" and updated. It can get tricky, > knowing which sectors in an eraseblock are available, and when a new > one > needs to be allocated. The OOB/metadata is on a per-page level. You don't have to erase a block just to write to a page when you know it's erased already. In particular: you can always flip a bit from 1 to 0. You need to erase to flip it from 0 to 1. That may be used to design an algorithm that uses the page as the primary granularity, while doing the erase on the block level. An algorithm like that would probably bundle pages with equivalent write frequencies in the same block... In any case: I don't know of any algorithms so I don't know if such an approach would be efficient at all. It may be something that just isn't going to work well and that you might as well use the block as the primary granularity. At this time I just don't see a reason to close the door on more advanced algorithms... -- Marcel Moolenaar xcllnt@mac.com