[LinuxBIOS] Winflashrom -- Current Status

[Darmawan Salihun]

On 7/25/07, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> * Darmawan Salihun <darmawan.salihun at gmail.com> [070724 06:11]:
> > I'm currently completing the MMIO mapping routine
> > in the device driver, but I have a problem as follows:
> > - The current driver doesn't limit the application
> >   to map certain MMIO phy address range even if it's
> >   already mapped by another routine in the same
> >   application. I actually plan to "lock" the mapped
> >   MMIO phy address range so that once it's mapped, it
> >   must be unmapped first before another routine can map
> >   that range. Actually, this is to avoid two routine
> >   from manipulating the same area at the same time.
> >
> >   My question is, do you think we really need the "lock-ing"
> >   mechanism in the driver? I just think it is a potential
> >   problem if the MMIO access is not "lock-ed".
>
> Since the places where mmap happens are only a few I'd say it is not
> really "needed". It's a good idea though as it is a safety measure
> against application bugs.


The MMIO mapping routine completed. I need more testing though.

Anyway, after evaluating all of the possible development path last week,
I came to conclusion that the robustness of winflashrom code and its
evolution
in to the future will be guaranteed if the architecture is as follows:
1. PCI detection routine in Windows is in "user mode" and parsing the data
from Windows device "database".
2. The driver will contain the chipset_enable and board_enable routine as
they are doing direct IO transactions which should be hidden from the user
mode application as much as possible to mitigate possible exploit in the
future. It will ease migration into WDK (ofr Windows Vista support in the
future) as well.
3. As before, user mode application part of winflashrom will be compiled
with MinGW and its driver will be compiled with Microsoft's native device
driver compiler that comes with their driver development kit. I decided that
this is the best approach because it will be problematic when we migrate to
Windows Vista and take a different route.

Anyway, the architecture above will make the winflashrom significantly
differ from flashrom.
However, "unification" with the flashrom base code is not impossible but I
think it's better to do it gradually. Peter's idea of using a "simple
protocol" to exchange data between the application and the driver for the
chipset_enable and board_enable routine sounds solid at the moment. I will
implement it for the rest of Google Summer of Code coding phase and I think
we will have a working code in about two weeks from now. However, I'm still
looking for other ideas in this matter.

Regards,

-- Darmawan Salihun a.k.a Pinczakko
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070729/4d12764f/attachment.html>