Date: Mon, 25 Feb 2008 09:30:32 -0500 From: "Andrew Duane" <aduane@juniper.net> To: "Marcel Moolenaar" <xcllnt@mac.com>, "M. Warner Losh" <imp@bsdimp.com> Cc: bms@freebsd.org, freebsd-embedded@freebsd.org Subject: RE: /dev/cfi NOR flash driver Message-ID: <0FCFCF6165E968449991746EB91D614D010318EC@antipi.jnpr.net> In-Reply-To: <33A08235-8501-432E-BB89-0F4A44D7F39A@mac.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. However, both need to support filesystems, hence both will need GEOM support. I'm working on NOR, but will likely be punting on full write support, at least for now. Or project only needs "wipe-and-rewrite" support, so I may just have a separate path (from the original CFI driver) for that. 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. owner-freebsd-embedded@freebsd.org wrote: > On Feb 23, 2008, at 8:30 AM, M. Warner Losh wrote: >=20 > > In message: <9C903216-6C19-4D6F-80D2-27C161845567@mac.com> > > Marcel Moolenaar <xcllnt@mac.com> writes: > > > We should have this integrated with CVS shortly. > >=20 > > cool! > >=20 > > btw, do you implement the mtd partitioning from Linux or not? >=20 > No, cfi(4) is just a simple driver that allows reading > and writing to NOR flash through the device special file. >=20 > The thought is to put some layering on top of it, which > deals more with how the NOR flash is being used. If there's > a file system on the NOR flash, then I expect we'll have it hooked up > to GEOM.=20 >=20 > I've been thinking about NAND flash and file systems and > so on and maybe we should merge the NAND and NOR flashes > and come up with a more generic sub-system. We could keep > MTD in mind, but after a quick read I'm not sure I like > their notion of only operating on the "eraseblock". It > seems to ignore the ability to read and write pages and > the fact that OOB is on a per-page level... >=20 > Anyway: I'll just import it. It has proven very useful for > us already in its current form and shape and if we want > to come up with something generic that encapsulates both > NOR and NAND, I'm sure that there's cut-n-paste value in having the > driver...=20 >=20 > Thoughts? /Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0FCFCF6165E968449991746EB91D614D010318EC>