The regressions pass, so it still works, it's simply a configuration issue with the generic scripts. The bridges used to be bi-directional and now they're uni-directional. Previously, when an i/o cache was added to a configuration filtering ranges had to be setup on the bridge to only allow traffic from one direction to flow through it (thus the requests would flow through the I/O cache). With the new changes the bridges are un-directional so in the no-caches case another bridge is required to allow requests to flow both directions in the case that no caches are present in the system. The issue with x86 is that it's not simply that uncached I/O flows into the i/o bus and the i/o devices dma to main memory. There is a third class, interrupt messages. To handle this x86 inserts a bridge makex86LinuxSystem() that allows the messages to flow out of the i/o bus, however the other ISAs need a bridge now too, which happens to be named the same thing. I'm pretty sure just changing the name of the bridge in makex86LinuxSystem will do it (it appears to work for me).
diff -r 223945df5510 configs/common/FSConfig.py --- a/configs/common/FSConfig.py Fri Feb 03 09:48:10 2012 -0800 +++ b/configs/common/FSConfig.py Fri Feb 03 18:03:27 2012 -0600 @@ -385,10 +385,10 @@ # Create a bridge from the IO bus to the memory bus to allow access to # the local APIC (two pages) - x86_sys.iobridge = Bridge(delay='50ns', nack_delay='4ns') - x86_sys.iobridge.slave = x86_sys.iobus.port - x86_sys.iobridge.master = x86_sys.membus.port - x86_sys.iobridge.ranges = [AddrRange(interrupts_address_space_base, + x86_sys.apicbridge = Bridge(delay='50ns', nack_delay='4ns') + x86_sys.apicbridge.slave = x86_sys.iobus.port + x86_sys.apicbridge.master = x86_sys.membus.port + x86_sys.apicbridge.ranges = [AddrRange(interrupts_address_space_base, interrupts_address_space_base + APIC_range_size - 1)] Ali On 03.02.2012 15:17, Gabriel Michael Black wrote: > So, my question is/questions are, what was this code doing before that > was working? What's it doing now that's different that makes it not > work? Why is it doing it that way instead of the way that worked before? > > Gabe > > Quoting Ali Saidi <[email protected]>: > >> Hmm.. I'm very surprised this works. The correct solution is to do something like: if test_sys.iobridge: test_sys.iobridge.ranges.append(AddrRange(mem_size)) else: #instaniate a bridge A third option may be to just all the x86 bridge something else ioapic_bridge and have two bridges (one handling each range). Ali On 03.02.2012 01:43, Joel Hestness wrote: >> >>> Hey guys, >> >>> Just ran into this myself. The IO bridge is being instantiated twice, >> once in FSConfig.py and again in the fs.py file. I was able to fix it for X86_FS simply by adding an if clause in the fs.py file (line 166) where it is instantiated the second time: test_sys.iobridge = Bridge(delay='50ns', nack_delay='4ns', ranges = [AddrRange(mem_size)] >> >>> %">test_sys.iobridge.slave = test_sys.iobus. >> uote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">test_sys.iobridge.master = test_sys.mem >> >>> -left:5px; width:100%">I' >> this would upset other architectures though. Joel have something to do gem5 is copyrighted software; use the --copyright option for details. exec filecode in scope File "/home/tkl245/gem5/src/python/m5/simulate.py", line 91, in instantiate portRef. >> >>> e 1485, in ccConnect [el.ccConnect() for el in self.elements] >> "padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">File "/home/tkl245/gem5/src/python/m5/params.py", line 1407, in ccConnect -Trang _______________________________________________ [email protected] [3] [3] > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users Links: ------ [1] mailto:[email protected] [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:[email protected] [4] mailto:[email protected] [5] http://www.cs.utexas.edu/~hestness [6] http://gem5.org [7] http://peer.name [8] mailto:gem5-users@<div> > 5sim.org/cgi-bin/mailman/listinfo/gem5-users [5] mailto:[email protected] [1] [6] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] [7] mailto:gblack </div>du</a>[8]<ahref=
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
