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

[Marcel Moolenaar]

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).

It's not easy, but probably worth thinking about...

> And thanks for this great work!

You're welcome. I hope it's a good start...

-- 
Marcel Moolenaar
xcllnt at mac.com