Why not have an keep the SouthBridge in the hierarchy to manage the pieces while having them all directly connect to the bus. This seems like a lot of work to get rid of a SimObject in C++ that won't be doing much.
Ali On Aug 21, 2008, at 4:46 PM, [EMAIL PROTECTED] wrote: > I don't think there's anything wrong with the southbridge as a > conceptual > object, but I thought having it in the SimObject hierarchy was a bad > idea > since, for instance in ancient PCs, all the little bits and pieces > we're > dealing with were their own entities. It's conceivable that in the > future these > things will even be on die. What I thought would be best was to make > all these > components first class objects that are directly attached to the > bus, etc, but > provide a SouthBridge python class that didn't exist beyond the > configuration > phase and provided a handy conceptual handle on all the bits and > pieces and > helped set them up properly. Since I don't want the SouthBridge to > be between > the legacy components and what refers to them (so that that sort of > relationship isn't mandantory), I need to find a way to get from the > PC object > to the timer directly without the timer having to cooperate. What > would be > best, I think, is if there was some way for a pointer to the timer > to persist > into C++ without it having to be a Param people could muck with, but > I don't > think that's currently possible. > > Gabe > > Quoting nathan binkert <[EMAIL PROTECTED]>: > >> What was wrong with the southbridge object? Was it because of the >> subdevice thing? I don't think you need to necessarily get rid of >> the >> southbridge, you can still have it to do the initialization that you >> want, I just think you want to make all of the things that were >> subdevices proper SimObjects. >> >> Nate >> >> On Thu, Aug 21, 2008 at 9:58 AM, <[EMAIL PROTECTED]> wrote: >>> The problem here isn't the memory locations things are attached >>> at, it's >> doing >>> some initial configuration on the 8254 which I believe the BIOS >>> would >> normally >>> do. If you look in the PC init function you can see where this is >>> happening >>> currently. The southBridge pointer (I think) is near the top and >>> it's used >> to >>> set the value for the timer pointer to point at the 8254. Since the >> southbridge >>> object no longer exists, that code won't work as is. In order to >>> avoid a >> loop in >>> SimObject references, I had the SouthBridge set a pointer back to >>> itself in >> the >>> platform object. I don't want to push that down into the 8254 >>> model because >> I >>> want to keep that a relatively generic device you could stick >>> anywhere, if >> you >>> so desired, that doesn't know it's part of the PC platform. >>> >>> Gabe >>> >>> Quoting nathan binkert <[EMAIL PROTECTED]>: >>> >>>> I'm not exactly clear what you're saying here. You had a >>>> SouthBridge >>>> object, and in south_bridge.cc, it looks like you manually set the >>>> memory locations of the various objects in the south bridge. >>>> Now, you >>>> want to make the individual objects normal SimObjects, but you're >>>> having trouble figuring out how to stick them at the right memory >>>> locations? What about a simple attachSouthBridge() function in >>>> python >>>> that take a platform object as a parameter and attaches the various >>>> objects at the right memory locations. Alternatively, you could >>>> just >>>> derive from the PC platform object and stick the south bridge >>>> stuff at >>>> the right memory locations in there as defaults. >>>> >>>> Do I understand the problem correctly? >>>> >>>> Nate >>>> >>>> On Wed, Aug 20, 2008 at 11:58 PM, Gabe Black >>>> <[EMAIL PROTECTED]> >> wrote: >>>>> Now that I'm flattening out the SouthBridge object, I'm ending up >>>>> breaking the solution I had before to allow the PC platform to >>>>> program >>>>> the initial state of the 8254 PIT. What would happen before was >>>>> that the >>>>> SouthBridge would tell the PC platform about itself, and then >>>>> later the >>>>> platform would get at the timer through the SouthBridge and >>>>> configure it >>>>> properly. Now there's no SouthBridge, and I don't want to push the >>>>> artificial initial configuration code down into the device >>>>> itself. One >>>>> possible solution I was thinking of would be to actually just do >>>>> functional accesses to the right locations to program the PIT like >>>>> software would. I'm not sure that would work, though, since I >>>>> don't know >>>>> if all the devices have been constructed or hooked up to the >>>>> memory >>>>> system yet. Another option would be to record in the PC >>>>> simobject where >>>>> the timer is since the timer is created and hooked up by the >>>>> python >>>>> version. I don't necessarily want to make it a Param though, >>>>> because I >>>>> don't want anyone to be able to modify what it's pointing at. >>>>> All the >>>>> other connections, to the 8259 PIC, the speaker, etc, will all >>>>> be to the >>>>> original object, so it won't do any good for the C++ PC object to >>>>> initialize something else. Any ideas? >>>>> >>>>> Gabe >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>> >>>>> >>>> _______________________________________________ >>>> m5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
