-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Sunday, November 07, 2010 03:15 PM To: Scott Duplichan Cc: 'Tobias Diedrich'; coreboot@coreboot.org Subject: Re: [coreboot] [patch 16/16] Ranges unavailable for PCI BARs shouldbemarked as reserved in the E820 memory map,in case the OS wants to change the BARs.
]Hi, ] ]I thought our resource allocator did not touch the high region because of ]lapic/hpet/apic stuff. Maybe it is no longer true. I got some issue with PCI ]sata add on card (linux complaining about resource overlap on SB700)
Hello Rudolf,
You are right about coreboot, at least for the present time. However, the allocation scheme still needs some work. For example, fec00000 and above is never allocated to a pci device because of the I/O apic, which is on the pci bus. However, mmconf is not protected from pci use, because it falls under 'APIC_CLUSTER: 0', and not a pci bus: http://www.coreboot.org/pipermail/coreboot/2010-October/061320.html
I think the immediate concern for reserving flash memory space is because the OS is allowed to make PCI resource assignments on its own. The OS could use any range not reserved in e820. However, windows, and possibly linux, also restrict PCI use to address ranges that ACPI _CRS show as belonging to the pci bus. Coreboot still needs work in this area. So maybe my example is a little far-fetched. But a commercial BIOS reserves all the memory decoded by the flash chip, so coreboot should probably do the same unless there is a specific reason not to.
]Maybe this is heading to same direction?
Could be. I have two overlap situations with win7 to avoid. One is the mmconf problem described above. The other is when two video cards are present, they both claim the legacy vga memory and I/O ranges.
]Thanks, ]Rudolf