[LinuxBIOS] Winflashrom -- Current Status

Darmawan Salihun darmawan.salihun at gmail.com
Thu Jul 12 12:13:38 CEST 2007

Peter Stuge wrote:
> 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.
It should be trivial to do that.

>> 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.
I see.

>> 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?
The base is in a PCI config register. Relevant code as follows:
------------------- board_enable.c ----------------------------------------
static int board_via_epia_m(const char *name)
    /* Get Power Management IO address. */
    base = pci_read_word(dev, 0x88) & 0xFF80;

    /* enable GPIO15 which is connected to write protect. */
    val = inb(base + 0x4D);
    val |= 0x80;
    outb(val, base + 0x4D);



More information about the coreboot mailing list