Hi Tim, The pros of bypassing power-on is that it is simpler, easier to change the kernel, and faster to boot. The down sides are that for OSes other than linux (e.g. Solaris) the kernel can't come in a monolithic binary which means more complexity of at least some kind. With starting at power-on you need to run something like open firmware to get the system into the appropriate place for the kernel to begin execution, it's harder to change the kernel (because it normally lives on a disk that the bootloader reads), and it takes a bit longer to boot.
Ali On Mar 25, 2010, at 7:42 PM, Timothy M Jones wrote: > 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
