svn commit: r184251 - in head/sys: conf dev/cfi sys

[M. Warner Losh]

In message: <0BBCA616-4F9D-48D5-9360-CACA69480632 at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> 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