> On 2012-01-10 22:39:30, Steve Reinhardt wrote: > > I can't see this diff (I think the repo update messed up reviewboard's > > ability to display it). > > > > Based solely on the description, I must say I'm a little sad to see the > > flexibility of the old system go (it was nice to be able to take a PCI NIC > > and stick it wherever we wanted in the memory hierarchy), but that code was > > kind of complicated, and it's not like a lot of other people took advantage > > of it.
It still should be possible to place a PCI device anywhere in the hierarchy, you just have to be slightly clever about it. PCI enumeration and resource allocation code generally doesn't move devices that are assigned by a pre-kernel environment. If you take the region of memory that could be allocated to PCI devices and statically assign the highest parts of the range to the devices that are placed in a non-standard location (and update the various bridge addresses) that should solve the issue. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/951/#review1892 ----------------------------------------------------------- On 2012-01-05 05:24:28, Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/951/ > ----------------------------------------------------------- > > (Updated 2012-01-05 05:24:28) > > > Review request for Default. > > > Summary > ------- > > MEM: Make the bus bridge unidirectional and fixed address range > > This patch makes the bus bridge uni-directional and specialises the > bus ports to be a master port and a slave port. This greatly > simplifies the assumptions on both sides as either port only has to > deal with requests or responses. The following patches introduce the > notion of master and slave ports, and would not be possible without > this split of responsibilities. > > In making the bridge unidirectional, the address range mechanism of > the bridge is also changed. For the cases where communication is > taking place both ways, an additional bridge is needed. This causes > issues with the existing mechanism, as the busses cannot determine > when to stop iterating the address updates from the two bridges. To > avoid this issue, and also greatly simplify the specification, the > bridge now has a fixed set of address ranges, specified at creation > time. > > > Diffs > ----- > > configs/common/FSConfig.py 09b482ee9ae0 > src/dev/arm/RealView.py 09b482ee9ae0 > src/mem/Bridge.py 09b482ee9ae0 > src/mem/bridge.hh 09b482ee9ae0 > src/mem/bridge.cc 09b482ee9ae0 > tests/configs/pc-o3-timing.py 09b482ee9ae0 > tests/configs/pc-simple-atomic.py 09b482ee9ae0 > tests/configs/pc-simple-timing.py 09b482ee9ae0 > tests/configs/realview-o3-dual.py 09b482ee9ae0 > tests/configs/realview-o3.py 09b482ee9ae0 > tests/configs/realview-simple-atomic-dual.py 09b482ee9ae0 > tests/configs/realview-simple-atomic.py 09b482ee9ae0 > tests/configs/realview-simple-timing-dual.py 09b482ee9ae0 > tests/configs/realview-simple-timing.py 09b482ee9ae0 > tests/configs/tsunami-inorder.py 09b482ee9ae0 > tests/configs/tsunami-o3-dual.py 09b482ee9ae0 > tests/configs/tsunami-o3.py 09b482ee9ae0 > tests/configs/tsunami-simple-atomic-dual.py 09b482ee9ae0 > tests/configs/tsunami-simple-atomic.py 09b482ee9ae0 > tests/configs/tsunami-simple-timing-dual.py 09b482ee9ae0 > tests/configs/tsunami-simple-timing.py 09b482ee9ae0 > tests/configs/twosys-tsunami-simple-atomic.py 09b482ee9ae0 > > Diff: http://reviews.m5sim.org/r/951/diff > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
