[LinuxBIOS] Winflashrom -- Current Status
darmawan.salihun at gmail.com
Sat Jul 14 05:13:00 CEST 2007
Stefan Reinauer wrote:
> * Peter Stuge <peter at stuge.se> [070712 17:27]:
>> Then compile board_enable.c also into the app, but not to call any of
>> the functions (which would fail anyway) but only to get the same
>> board_pciid_enables list. The struct may have to be extended to have
>> a unique index for each entry so that the driver and app can agree on
>> which function is which.
>> All of the device detection should be done where it is easiest to do
>> it. Since the driver will need to do safe PCI accesses for board
>> enables perhaps it makes sense to contain all PCI accesses in the
>> On the other hand, perhaps the app will need to do some PCI accesses
>> to choose the right board_enable function and then it's better to do
>> most of them in the app.
>> What do you think?
> Application logic belongs into the application, not into the driver.
This makes me wonder if the current driver is good enough :-/
>> Another general matter, make sure the app and driver can exchange
>> version numbers. That way both the driver and the app could have
>> compatiblity code in order to be backwards compatible.
> The driver should be stupid enough so it does not need to be changed.
> There is no need for a driver in Linux, either, it's merely a makeshift.
The reality is the current driver is as stupid as it is. Because, it
to every direct I/O functions (inb, outb, etc.) in the correct manner
the requested physical address range as we expect from mmap'ing /dev/mem.
However, I'm thinking and experimenting about moving the board_enable
support to the driver, so that every low-level accesses is kept to the
Which implementation approach do you think is best ?
Honestly, looking at the current "design paradigm" that I can read from
the simplistic approach is the one that fits the original flashrom.
But, I left the decision to all of us here.
More information about the coreboot