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
