On 5/1/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- 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.
- 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
- 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.