<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Peter Stuge</b> <<a href="mailto:stuge-linuxbios@cdy.org">stuge-linuxbios@cdy.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:<br>> 1. The kernel mode code a.k.a kernel mode device driver is as<br>> simple as possible and only provides "raw" functionality, i.e.<br>> capability to map the physical address space in which the BIOS
<br>> chip is mapped into the requesting user mode code.<br><br>This would be OK, but there's a constant race between making the<br>window large enough and new flash chips.<br></blockquote>In my current experimental code. The "window" in the kernel driver is programmable, 
i.e. the user mode application <br>passes the starting address of the MMIO range along with the size of the range to be mapped. <br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> 2. The kernel mode driver implements the majority of the flashrom<br>> code and the usermode code is merely a "front-end" to the kernel<br>> mode device driver which provides all of the chip related logic.
<br><br>I like this a bit better.<br></blockquote>I see. My problem right now in this version is to define the interface between the kernel driver and the user mode code.<br>Quite hard to define the interface because it will use a quite different approach than the "mmap" approach in point 1. 
<br>It requires me to write wrapper functions and "decouples" the original routine in the linux version of flashrom. Nonetheless, <br>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 
<br>my testbed.<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Anyway, I'm also thinking about a quite "universal" interface
<br>> between the user mode code and the kernel mode code. Perhaps a well<br>> defined interface<br><br>This requires a lot of extra work but has the benefit of only one<br>generic algorithm being implemented in the kernel, thus the kernel
<br>driver will not have to be updated to support new flash chips. It<br>could however have to be updated when a new driver supporting all<br>SPI flash is released. (But not every time a new flash chip is<br>added.)<br></blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">After having identified the chip the app would download the<br>appropriate microcode to the kernel driver; a set of rather
<br>high-level instructions to be executed by the driver.<br></blockquote>yes. That's why I'm currently thinking about the "evolutionary path" to this kind of functionality<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>1. or 2. will be a lot less work though. Maybe start there.<br><br>I like 2.<br></blockquote>I'll have a look at this approach more closely.<br></div><br>