I agree with what Ali said and wanted to add some info about the OS. If you choose Linux (which is a good but not the only choice) then you'll want to compile a version with whatever bells and whistles you want to attempt to get to work. What you do with it depends on how you've decided to boot strap the POWER hadrware. If you do something like we did for SPARC where you start from the power on and do everything in between, you'll build a disk image like you normally would and let the established mechanisms do what they're supposed to. Alternatively you could do what everything else does and load the kernel into memory manually and start executing it directly. To do that, you'll grab the non-compressed version with symbols (which are optional but extremely nice to have) and load it like an ELF executable in SE mode. The --kernel parameter in fs.py is for that.
To expand on Ali's number 4, you'll need to implement any POWER only devices that (or whatever OS) will expect to find. You should be able to take advantage of the IDE controller that's already implemented, and potentially some other devices. You'll also need to implement a Platform object which will likely be pretty simple, a System object, and an Interrupt object to implement POWER's CPU oriented interrupt semantics. If POWER has any in memory structures set up by the system firmware (a la the BIOS in x86), then you'll probably want the System object you implement to build those tables in memory for you. If you go the route of actually running some system firmware you won't (I don't think) need to do that, but then you'd actually need to write or get ahold of that firmware. In my opinion, in ISAs without lots of extra gunk at the system level, implementing FS after SE isn't that bad. Devices are (often) relatively easy to debug if they're docs are decent, and while the kernel starts switching between contexts after a while (pretty far into boot, actually), it's not that much harder to work with than an SE mode binary. Even if you decide to work on FS and later decide it's not worth continuing, at least some work will be done and someone else can get a head start. Gabe Quoting Ali Saidi <[email protected]>: > > Hi Tim, > > Without having looked at your Power implementation or knowing a great deal > about the ISA these comments are pretty generic. > 1) Implement privileged instructions > 2) Memory translation, TLB, interfaces to load TLBs > 3) Faults/Interrupts (generated from things like translation and external > events) > 4) Required peripherals, in-memory data structures, etc. > 5) A method to boot the system, generally this means doing whatever the > BIOS/firmware is doing to make the system ready to jump to the kernel. > Solaris is the exception here where we run the firmware, but it's a bit of > a pain. > > The time do to the above is half dependent on how complex these items are > in Power and how similar some are to existing ISAs support, and half > dependent on your strategy for validating your implementation. With SPARC > we used the golden brick method from the start, with Alpha/Tsunami we > didn't have a golden brick, so when an error showed up, the question was > were in originated (possibly billions of instructions earlier). > > Ali > > > > On Thu, 25 Mar 2010 08:52:11 -0400, "Timothy M Jones" > <[email protected]> > wrote: >> Hello, >> >> Could anyone briefly run through the steps I'd have to take to get Power > >> ISA working in Full System mode? It's something that I've been thinking > >> about for a while, but I basically don't have a clue where to start or > the >> >> work that would be involved. If someone could give me a rough estimation > >> of the time they expect it to take too, then that would be great. That >> would influence when/if I started to work on it. >> >> Thanks >> Tim > _______________________________________________ > 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
