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

[Darmawan Salihun]

On 5/1/07, Peter Stuge <stuge-linuxbios at cdy.org> 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
> > simple as possible and only provides "raw" functionality, i.e.
> > capability to map the physical address space in which the BIOS
> > chip is mapped into the requesting user mode code.
>
> 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.


> > 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 requires me to write wrapper functions and "decouples" the original
routine in the linux version of flashrom. Nonetheless,
I haven't built any experimental code with this approach yet. Unlike the
approach in point 1, it seems to be working so far in
my testbed.



> > 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
> driver will not have to be updated to support new flash chips. It
> could however have to be updated when a new driver supporting all
> SPI flash is released. (But not every time a new flash chip is
> added.)
>
After having identified the chip the app would download the
> appropriate microcode to the kernel driver; a set of rather
> high-level instructions to be executed by the driver.
>
yes. That's why I'm currently thinking about the "evolutionary path" to this
kind of functionality


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070501/8058fbf6/attachment.html>