Hi Andreas,
On 12/04/2013 23:37, Andreas Hansson wrote:
It sounds like there are plenty things going on here, and that you already
got quite far in your debugging.
Thanks for your encouragement!
The bridge has no clue of any 32/64 bit BAR, it cares only about the
physical 64-bit address ranges,
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),
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.
If I remember
correctly, you also have to ensure that the pciconfig is the default slave
and that the address mapping is ignored for that range.
Won't the bus instance (iobus, in this case) only route messages 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.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
