[LinuxBIOS] Winflashrom -- Current Status

[Peter Stuge]

On Thu, Jul 12, 2007 at 02:19:47PM +0700, Darmawan Salihun wrote:
> 1. Libpci abstraction for Windows. In this case the libpci logic in
> the flashrom code base need not be changed. I will make a "libpci
> for Windows" that doesn't change the logic within the current
> flashrom code. Even after the redesign, we might choose to preserve
> this part.

Perhaps you can make a small libpci-win32 package out of it? I'm sure
others would appreciate it as well.


> 2. Direct I/O access abstraction. I think, in the short term, I
> will just provide a simple direct I/O "compatibility layer" for
> inX,outX family of functions in the winflashrom.

This can just be some #defines, use some functions in Windows and the
normal in()/out() stuff otherwise.

Put this in some header:

#ifndef __WIN32__
#define my_inb(a,b) inb(a,b)
#define my_inw(a,b) inw(a,b)
#define my_inl(a,b) inl(a,b)
#endif /* __WIN32__ */

..and then implement my_in[bwl]() in a .c file together with all the
other stuff needed for Windows. Have a conditional in the Makefile to
build and link that file on Windows only. Voila, done.


> 3. File I/O abstraction. We might need this because fopen(..)
> behaves not exactly the same in Windows and *NIX.

C89 has the b mode so just change all fopen calls to use "rb", "wb",
"ab", "rb+", "wb+" and "ab+" respectively.


> do you think it's good to make a branch for the current flashrom
> code in order to develop the unified (redesigned) flashrom that
> will host a single code base for both the *NIX version and
> winflashrom?

Is that really needed? Just submit nice and neat patches against
trunk to get them reviewed, acked and applied.


> Another note that I have difficulty in limiting the direct I/O
> access in the current driver because I don't know exactly which
> port to give access to and which one to block. Below is what I've
> found from the current flashrom code so far. I/O port usage:
> 
>        0x2E (Winbond W836_INDEX port)
>        0x2F (Winbond W836_DATA port)
>        0x4E
>        0x4F
>        0xCD6
>        0xCD7
>        0xCFC - 0xCFF (PCI I/O port on x86)
>        0xC6F
>        a "base + 0x4D" in Via Epia motherboard
>        0xE1
>        0xE800 (what port is this? )
>        0xE801
>        0xE802
>        0xE803
>        0xE804
>        0xE807
>        0xEB
>        0xFF
>       
> I couldn't conclude the the I/O port ranges to open from the port
> list above because there is still unknown (I think it's dynamically
> relocatable) I/O port such as the one used by EPIA board.
> Any explanation on this issue?

This list is still much better than allowing everything!

As for the EPIA board, well, where is that base specified? In a PCI
config register or where?


//Peter