[LinuxBIOS] RFC Winflashrom Architecture -- Current device driver (testbed)

Jeremy Jackson jerj at coplanar.net
Mon Jun 11 16:58:55 CEST 2007


I've thought about this a fair bit, going way back a year or more ago,
to when I started porting the DevBIOS project to Linux MTD framework.

Overall I disagree with flashrom being in userspace.  

There is the issue of mapping PCI roms to free areas, locking (can you
use the EEPROM socket on a NIC while it's receiving a frame?).

I have an idea of how the #2 layer would go, with the hardware access
done in the kernel.  My first guess is that the library of flash parts
would be in the kernel (yuck), or at least the current chip's parameters
could be loaded into the kernel driver with an IOCTL which stops kernel
bloat and eases updates for new flash parts.  This would let whole
chip/sector erase, sector program of varying sector sizes, and any other
chip specific functions be supported safely.

A simple whole-chip programming could be done with 

  # cat bios.rom > /dev/bios 

style command, while the flashrom2 userspace tool could read the current
chip's sector sizes, and selectively program with simple read()/write()
calls.

With the hardware access moved into the kernel, the userspace tool(s)
could focus on partial updates of code (boot block vs fallback vs normal
images), userspace initramfs, kernels (on 2MB flash parts).

One thing that should really drive this home, is that using this
architecture on Linux *and* Windows, the same userspace tool could be
used on both, so the fancy code for incremental updates, writing
parameter blocks, etc.,  wouldn't have to be duplicated.

Isn't MTD framework capable of handling most of this already?

Regards,

Jeremy

On Wed, 2007-06-06 at 18:00 +0200, Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
> > I know, it's not a good example of software engineering practice.
> > Nonetheless, I want to discuss, on which API that I should be
> > removing from user mode application accesses and which one to
> > retain.
> 
> I couldn't make out much of it.
> 
> Again, I think the evolution goes like this:
> 
> 1. Kernel driver allowing unrestricted reads and writes to top 16MB.
> 
> 2. Kernel driver implementing the lowest level flash chip API.
>  Possibly using some macro language so that reboot isn't neccessary
>  to upgrade flash support.
> 
> API details can't really be that complicated until (2) but I don't
> think we can get away from doing (1) first so no need to worry about
> (2) yet.







More information about the coreboot mailing list