[LinuxBIOS] RFC Winflashrom Architecture -- Current Progress
Darmawan Salihun
darmawan.salihun at gmail.com
Wed Jun 27 13:28:02 CEST 2007
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
>
>
>
>
>
More information about the coreboot
mailing list