[LinuxBIOS] RFC Winflashrom Architecture -- Current Progress
Darmawan Salihun
darmawan.salihun at gmail.com
Wed Jun 27 12:52:56 CEST 2007
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).
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