Hi David,
On 18.04.2013 12:30, David Miller wrote: > Of course, BARs are a PCI thing. > >> and if you add a range that is unique (not in the normal memory range for example) it should work fine. The bus will tell you if there are multiple destinations for the same address. Could you perhaps post these few lines that you've added? > > Short term, I've manually hacked in the relevant range, just to prove it > works. It does. Inserted into the system.bridge.ranges list: > >> AddrRange(0x10000000, 0x1001ffff), There is some range where PCI memory/IO space is expected to be allocated and it seems like this allocation just isn't in the bridge range? Isn't this the same range that is needed for the Ide Disk (or peraphs those are all IO ports)? > suddenly I get messages from membus to the effect that this range is > connected to the bridge. > > (Obviously, this is inadequate long term, particularly when I begin to > mess about with bus hierarchies. I'm in the process of figuring out how > to propagate the rangeChange messages through the bridge.) > > Manual attempts to read from this range work (and the device indicates > that it's receiving the read request with the appropriate trace flag > turned on). > > But, the kernel is still faulting with the same ioremap() error when the > igb driver attempts to initialise. > > If the sim is correctly handling reads, yet the kernel is getting > confused, presumably the problem exists between the system configuration > and the kernel. How does the kernel figure what ranges are valid? I've > tried poking around in the sources, but get stumped at the function > phys_addr_valid() in arch/x86/mm/ioremap.c. I don't really know how this works on x86, but I'd guess it's a field in the ACPI table or something that is passed to the kernel. If I remember correctly, you also have to ensure that the pciconfig is the default slave and that the address mapp > sages to the default port if it receives a message for which it doesn't already have an explicit range mapping? If so, then even in a hierarchy of buses, messages should still go to the right place provided suitable range messages have been sent upwards through the tree (which they must anyway, else the membus will reject the message as was originally happening). > >> You can also have a look at dev/arm/Realview.py for more examples of how this is done. > > Unless I've missed something, this only demonstrates how to statically > allocated address ranges. pciconfig is handled in a similar way in Pc.py. > > David. > > The way this is supposed to work is the kernel will program up the PCI device with a range that the bridge allows to pass, and then the range updating on the buses will route the message there. There is generally only one default port that gets the message and it's what is returning the BadAddr error that you saw p Thanks, ALi
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
