Re: constraints on rbus_min_start?

[nathanw%MIT.EDU@localhost (Nathan J. Williams)]

"Steven M. Bellovin" <smb%cs.columbia.edu@localhost> writes:

>> NetBSD doesn't normally do this on desktop boxes; we assume that the
>> firmware has done it. The option to probe and allocate all the BARs
>> ourself (PCI_NETBSD_CONFIGURE) is more commonly used on embedded
>> systems with minimal or PCI-unaware firmware. 
>> 
>> If PCI_CONFIG_DUMP is enabled, we will read the existing values and do
>> the read/write/read/rewrite dance to size the BAR but restore the
>> firmware-programmed value; I don't think that data is saved anywhere
>> but the dmesg output.
>
> I'm not sure which firmware you mean -- individual devices?  the BIOS?

The BIOS. Someone has to take the responsibility of scanning the PCI
tree, enumerating the devices, figuring out how much space each one
wants, and writing the appropriate address into the BAR. On desktop
systems, that's usually the BIOS; on embedded systems, it's more often
us.

> -- but the answer seems to be that (a) NetBSD generally doesn't know
> where PCI devices live in memory address space; (b) if it finds out, it
> doesn't store the information anywhere; (c) there isn't a good
> alternative to guessing to locate the Cardbus space; (d) guessing won't
> work for machines with a lot of RAM; (e) for now, at least, I'm SOL if
> I choose to run amd64, because fixing this is a fair amount of
> work...

(a) needs a slight clarification. It's easy to enumerate PCI and find
out where things are; the PCI attach routines do this, and it's what
"pcictl dump" does. It's finding the size/extent of each block that's
somewhat annoying, because you have to disable the device to do it
safely. For (b), it is true that we don't keep track of everything we
see taking up space in a centralized way. For devices we do attach,
there's some extent object being used by the bus_space_alloc()
routines, but that doesn't account for unattached/unsupported devices.

        - Nathan