[LinuxBIOS] Winflashrom -- Current Status
Peter Stuge
peter at stuge.se
Thu Jul 12 10:05:56 CEST 2007
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
More information about the coreboot
mailing list