[LinuxBIOS] Winflashrom -- Current Status

Darmawan Salihun darmawan.salihun at gmail.com
Fri Jul 13 11:27:21 CEST 2007


Peter Stuge wrote:
> On Thu, Jul 12, 2007 at 05:13:38PM +0700, Darmawan Salihun wrote:
>   
>>> 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:
>>
>>     base = pci_read_word(dev, 0x88) & 0xFF80;
>>
>>     val = inb(base + 0x4D);
>>     val |= 0x80;
>>     outb(val, base + 0x4D);
>>     
>
> Ok! Put all of board_enable.c in the kernel driver and add some way
> for the app to call any function in the board_pciid_enables list, in
> the kernel driver. Sort of RPC but over a app/kernel split instead of
> over a network.
>
> 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.
>   
I'm thinking about creating a board_enable.h file which will hold
the "board_pciid_enables list". It may be easier this way because
both the app and the driver will refer to it. Therefore, whenever
a change is happening, both will conform to the change immediately.
Of course board_enable.c will exist in the app and the driver as well.
Is that acceptable? or perhaps is it opening too much of access into a
"should be private" entity (in this case "board_pciid_enables list")?

> 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
> driver.
>
> 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?
>   
I think it's better to move it to the kernel driver and  
only provides a function call to it in the app. I think that's 
the way to go. However, that would be a huge #ifdef in the beginning 
of the transition into a new unified architecture :-(.


> 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.
>   
It's quite easy to add this capability in the driver initialization.
> I would like the app to exit with an error message if it can't agree
> with the kernel driver on a "protocol version" that both of them
> support. Need not be fancy right now, a simple two-way version check
> is plenty good.
>   
roger that ;-).

--Darmawan Salihun






More information about the coreboot mailing list