[LinuxBIOS] winflashrom architecture (Windows port of flashrom) -- looking for suggestions

[Darmawan Salihun]

On 5/2/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
> On Tue, May 01, 2007 at 11:20:20PM +0700, Darmawan Salihun wrote:
> > >On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
> > >> 1. The kernel mode code a.k.a kernel mode device driver is as
> > >
> > >This would be OK, but there's a constant race between making the
> > >window large enough and new flash chips.
> >
> > In my current experimental code. The "window" in the kernel driver
> > is programmable, i.e. the user mode application passes the starting
> > address of the MMIO range along with the size of the range to be
> > mapped.
>
> The problem with this is that the app could map ALL memory and
> destroy the system and/or data, even if by mistake. Not pretty.
>
I see, I overlooked the issue previously. This should be in my top list of
consideration ;-).


> >> 2. The kernel mode driver implements the majority of the flashrom
> > >> code and the usermode code is merely a "front-end" to the kernel
> > >> mode device driver which provides all of the chip related logic.
> > >
> > >I like this a bit better.
> >
> > I see. My problem right now in this version is to define the
> > interface between the kernel driver and the user mode code.
> > Quite hard to define the interface because it will use a quite
> > different approach than the "mmap" approach in point 1.
>
> It depends on how high level the driver tasks should be.
>
> I would model this after flashrom command parameters.


ok. This hint is helpful ;-).

> >> Anyway, I'm also thinking about a quite "universal" interface
> > >> between the user mode code and the kernel mode code. Perhaps a
> > >> well defined interface
> > >
> > >This requires a lot of extra work but has the benefit of only one
> > >generic algorithm being implemented in the kernel, thus the kernel
> >
> > yes. That's why I'm currently thinking about the "evolutionary
> > path" to this kind of functionality
>
> Sure. Better a hack that works than nothing. :)
>
>
> > >1. or 2. will be a lot less work though. Maybe start there.
> > >
> > >I like 2.
> >
> > I'll have a look at this approach more closely.
>
> Maybe you can actually identify trivial things that change in
> flashrom and create a small protocol for the application to specify
> them to the kernel driver.
>
> The app could enumerate the PCI devices in the system and compare
> that with a list of write enable functions that are implemented in
> the driver. (The driver tells the app which functions are available,
> the app decides which one to use.)
>
The current PCI device enumeration uses a cut-down version of the pciutils
source code
which I port to Windows (Quite trivial given the availability of inb,outb,
..., in the current kernel driver).

Most of the time a new flash chip can be added to flashrom just by
> adding it's parameters to the chip table. If this table was in the
> application a lot would already be gained.
>
yes, of course this should be in the priority list.

-- Darmawan
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070502/8037b45c/attachment.html>