[LinuxBIOS] Winflashrom -- Current Status

Darmawan Salihun darmawan.salihun at gmail.com
Tue Aug 14 10:07:49 CEST 2007


Roman Kononov wrote:
> Peter Stuge wrote:
>> But PCI config accesses are not atomic operations. Is there a
>> guarantee that the other CPUs are not in the middle of doing a PCI
>> access already?
>>
>> And even if they are actually doing something else, perhaps they
>> (erroneously? but we don't want to break them anyway) rely on 0xcfc
>> being what they set it to in the last PCI config access?
>>   
> By making all the CPUs spinning inside your DPC you avoid these 
> problems. The Windoze kernel protects itself and does not execute 
> scheduled DPC when the CPU is in the middle of a PCI access or anything 
> similar. For sure, when a CPU makes a PCI access its "IRQL" is raised to 
> "HIGH_LEVEL", which means that a dedicated spin lock is acquired and 
> that CPU's interrupts are disabled.
> 
> I did not take the above statement about IRQL from an official document, 
> I made it based on my experience and common sense.
> 
> Regards,
> 
> Roman
> 

Apparently, this is the only solution right now because the
Hal***BusDataByOffset() function is _not_ working as expected.

My latest test results with 2 different PCs with WIndows XP SP2 shows
that HalGetBusDataByOffset() is not a stable function, it works in one
of the test platform and crashes in others. While the
HalSetBusDataByOffset() is _not_ working at all. I think the symbol is
defined in the kernel but may not be implemented in Win XP SP2.

Moreover, direct port I/O was working flawlessly with the older flashrom
that I port to windows back then. I think the "DPC" trick will guarantee
the atomic operation and will give us the level of confidence to do the
direct port I/O.

I'll be reporting as soon as the DPC version of the direct port I/O
driver routine has been tested.

Regards,
Darmawan Salihun




More information about the coreboot mailing list