----- Original Message ---- > From: Myles Watson <[EMAIL PROTECTED]> > To: Marc Jones <[EMAIL PROTECTED]>; Coreboot <[email protected]>; ron > minnich <[EMAIL PROTECTED]> > Sent: Tuesday, November 11, 2008 7:42:57 AM > Subject: RE: [coreboot] Resource allocation
> > > My question is if resources ever split. In other words, lets imagine a > > > device which implements several IO ports in the 0x3fX range and larger > > > regions that must be mapped above 0x1000. Since the limit for the > > smaller > > > regions is 0x7ff and the alignment for the larger regions is 0x1000, > > they > > > both can't coexist. > > > > > > What happens? > > > > Everything > > below 0x1000 is legacy IO space and are not typically used by PCI > > devices (some devices/firmware sneek some stuff in around 0x800 for > > ACPI). As you noted there are some devices that might need to decode > > legacy regions to boot. If that is the case they will usually have a > > legacy enable bit in the header. In legacy mode the PCI BARs are > > ignored. The firmware, option ROM, and driver need to be aware of which > > mode it is in. An example is the AMD sb600 IDE controller(Device 20, > > Function 1). There is a legacy/PCI mode in the revision register ot > > offset 0x8. > > Thanks Marc. > > All right. So the legacy IO resources shouldn't be grouped with the others. > Should they be marked Subtractive? Are they declared to be special in a > different way? Yes but those legacy addresses could be positively decoded anywhere along the subtractive path. They will usually go as far as the chipset with an integrated controller. So, if someone put a legacy IDE controller farther on the path it (like lpc) it would never get the IO. For completeness in the dts you could have all the addresses in the system but I don't know if it is that important. I guess we need to add legacy io reserve code to the chipsets similar to the SIOs. Note that the exception to the subtractive decode is the VGA snoop and VGA enable (just for legacy VGA registes 0x3Cx -0x3Dx I think). Marc -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
