[LinuxBIOS] Winflashrom -- Current Status
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.
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.
More information about the coreboot