[LinuxBIOS] RFC Winflashrom Architecture -- Current Progress

[Darmawan Salihun]

Darmawan Salihun wrote:
> Hi all,
>     I want to report the progress that I made so far. Here they are:
>
> 1. The client (user mode) code is compilable with MinGW (currently
> carried-out in Msys console).
>     However, there are a few drawbacks:
>     a. PCI accesses (libpci) is implemented using direct-I/O access
> through the driver.
>     b. Other variations of in/out  routine is also still direct-I/O
> access through the driver.
>     c. Memory mapping is already implemented. I'm still finishing the
> limit of the physical memory ranges
>        that should be "map-able" in the driver.
>     d. The user mode code and the driver hasn't been integrated into one
> executable file yet. Note that it used
>         to be unified in a single executable file with the driver
> integrated as a binary resource and loaded dynamically
>         at runtime in my experimental code that was built with Microsoft
> VC++.
>
> 2. There is a possibility to use _only_ MinGW to build all of the
> components, including the driver.
>     The driver can be built by using winpooch methodology:
>      http://sourceforge.net/docman/?group_id=122629
>
> OK. So that's the general overview for now.
>
> Anyway, I want to ask a few details regarding the source code.
> 1.) Because there is _no_ reliable functions for sleep() and usleep()
> that works seamlessly (portable with no logic differences)
>      between the Windows version and the *NIX version. I'm using
> myusec_delay() instead to replace those function
>     to provide delay. Is that acceptable? or should I try using high
> resolution timer in Windows NT/2K/XP instead?
>     Note that Sleep() in Windows uses a different measure of time (in
> milliseconds) compared to sleep() in *NIX (which is
>    measured in seconds).
>   
I forgot to say that it's possible to use high resolution timer from
Windows API instead.

> 2.) Is there any "definitive" or "semi-definitive" I/O port address
> ranges that I suppose to give an  R/W access? I mean, right now
>      the 64K I/O space is  opened for access in the driver :-(. It
> should be easy to limit the I/O port address range. However,
>      I need to know those ranges.
>
> OK. That's it. I plan to sign-off/submit the changes this week to
> mailing list on saturday or sunday. Just for evaluation ;-).
> It shouldn't be ack-ed because the driver is still troublesome as is the
> libpci and some others.
> Nonetheless, I need feedback on the real code. That's why I think it's
> important to do that ASAP. It should've been last week.
> But, I have some local issues here that I must take care :-(.
>
> And some info: The mmap function in Unix is compatible with
> memory-mapped file in Windows. Nonetheless, because there is no
>                         such an analogy for /dev/mem in Windows. It's
> useless to use the windows port of mmap() because it won't be able
>                        to map the physical address range. Therefore, we
> still need the driver that I've used for some time now.
>
> Cheers,
> Darmawan   
>    
>   
>
>
>