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
