This is more or less what I was suggesting. Everything can be a first class SimObject, and all of the devices can attach to the bus, and the SouthBridge C++ object can do all of the proper pointer setup and device initialization.
Nate > 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 > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
