From owner-svn-src-head@FreeBSD.ORG Tue Oct 28 03:47:07 2008 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32BE4106566B; Tue, 28 Oct 2008 03:47:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADE08FC0A; Tue, 28 Oct 2008 03:47:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9S3icwb007895; Mon, 27 Oct 2008 21:44:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 27 Oct 2008 21:45:47 -0600 (MDT) Message-Id: <20081027.214547.709404828.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <0BBCA616-4F9D-48D5-9360-CACA69480632@mac.com> References: <200810250618.m9P6ICWl023370@svn.freebsd.org> <20081027153345.d4e9dcad.stas@FreeBSD.org> <0BBCA616-4F9D-48D5-9360-CACA69480632@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@FreeBSD.org, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r184251 - in head/sys: conf dev/cfi sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 03:47:07 -0000 In message: <0BBCA616-4F9D-48D5-9360-CACA69480632@mac.com> Marcel Moolenaar writes: : : On Oct 27, 2008, at 5:33 AM, Stanislav Sedov wrote: : : >> Add a driver for flash memory that implements to the Common Flash : >> Memory Interface (CFI). The flash memory can be read and written : >> to through /dev/cfi# and an ioctl() exists so processes can read : >> the query information. : >> The driver supports the AMD and Intel command set, though only : >> the AMD command has been tested. : >> : >> Obtained from: Juniper Networks, Inc. : > : > Do you plan to introduce some infrastructure so other flash-like : > drivers could be attached (e.g. non-CFI compliant, SPI flashes, etc)? : > I've started working on such thing and don't want to do the duplicate : > works, so if you have something in mind it's time to share:-) : : I have been thinking about it, but I don't have anything : yet. As it is, I probably won't have the time for it : either. If you started with something, then feel free to : take cfi(4) and integrate it. : : Also, access to the raw flash is nice, but one typically : uses it for various things. It would be great if we had : an infrastructure in which we could allow access to the : flash through more high-level interfaces. For example: : The flash may contain U-Boot (possibly with embedded : environment), FreeBSD loader, separate blocks for U-Boot : environment, a file system, etc. Those parts of the : flash that are used for disk-like storage should ideally : be exposed through GEOM. Environments should ideally be : exposed through a standardized interface so that we only : have to write a single utility to modify environments. : Open Firmware and/or EFI environment variables could then : also be exposed through that interfaces, eliminating the : need for drivers like powermc_nvram and special-purpose : tools like nvram(8). That's the main reason I made the SPI flash support I did on the at91rm9200 be a block device: people could update the flash part w/o the need of a special program, just dd. Ditto for the i2c eeprom stuff... I tend to think that we should handle the partitioning in GEOM, with higher level things figuring the rest out. We should expose flash, and its properties upstream in GEOM, but not have a separate layer for flash ala mdt. Warner