Loading the kernel is generally a lot simpler and easier and gets you 99% of the same thing as far as research use goes. Booting from power on is more flexible, though, since it makes it possible to boot something other than an ELF. I just started doing things that way for SPARC if I remember correctly, but it accommodated booting into the UltraSPARC hypervisor.
Gabe Quoting Timothy M Jones <[email protected]>: > Thanks very much for the information, guys. Could you just tell me what > the pros and cons are of each approach - starting from power on vs loading > the kernel manually into memory? Is one way a preferred approach over the > other? > > Cheers > Tim > > On Thu, 25 Mar 2010 14:34:31 -0400, Gabriel Michael Black > <[email protected]> wrote: > >> 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 >> > > > -- > Timothy M. Jones > http://homepages.inf.ed.ac.uk/tjones1 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > 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
