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
