I know why it wouldn't compile now. For some reason it just wasn't happy with SUNW,Sun-Fire-880 but once I moved to SUNW,Sun-Fire-T200 it worked like a charm!
On Tue, Mar 3, 2009 at 11:35 PM, Ali Saidi <sa...@umich.edu> wrote: > SUNW,Sun-Fire-T200 > On Mar 3, 2009, at 9:48 PM, Polina wrote: > > > Hi Ali, > > > > Thanks for your help. I hate to keep asking things, but there's little > > documentation. I appreciate you taking the time to respond to my > > emails. > > > > Oh, I see now. Would I follow the procedure outline in OpenSPARC > > readme > > files for creating checkpoints and copying stuff into the booted > > sparc? > Not for creating a checkpoint, that needs to be done within M5, but > the instructions for putting stuff on the disk image should be about > the same. Mount the image on a solaris machine, copy files in there, > done. > > > > > > Also, did you have any problems compiling things like hypervisor? I > > keep > > getting all kinds of errors, like > > > > > > ../../..//hypervisor-tools/bin/qas: > > "../../..//greatlakes/common/src/version.s", line 62: error: > > redefinition of symbol "qversion" > > ../../..//hypervisor-tools/bin/qas: > > "../../..//greatlakes/common/src/version.s", line 67: error: > > redefinition of symbol "eqversion" > > ../../..//hypervisor-tools/bin/qas: > > "../../..//greatlakes/common/src/version.s", line 69: error: > > redefinition of symbol "printversion" > > ../../..//hypervisor-tools/bin/qas: > > "../../..//greatlakes/common/src/version.s", line 78: warning: size of > > "printversion" redefined > > What could be causing them? > > You need to compile it on a Solaris machine. You don't really need to > compile the hypervisor unless you want to modify it. The files you > care about are in legion/src/config/niagara/*.conf and the associated > make files in there. These too need to be "compiled" on a solaris > machine. If you look at 1g2p.hdesc you'll see: > > CPU(0,guest0,0) > CPU(4,guest0,1) > > I tried changing that 4 to 1 (e.g. CPU id 4 -> 1) and it didn't > convince the hypervisor that I was interested in CPU1 not 4. Perhaps > there is another place that it is used or something else. > > Ali > > > > > > Thank you. > > > > Polina > > > > > > > > Ali Saidi wrote: > >> T1.... The hv and md description files need to match the > >> configuration > >> you're running. If you're only running 1 processor you need to change > >> the hv and md files to the 1up configuration (as opposed to the 1g2p > >> versions). > >> > >> Ali > >> > >> On Mar 3, 2009, at 9:10 PM, Polina wrote: > >> > >> > >>> Ali, > >>> > >>> Just to be sure, are you using T1 or T2 release of OpenSparc? > >>> Thanks. > >>> > >>> Polina > >>> > >>>> Well, it's probably best to actually make 2 CPUs work and then go > >>>> back > >>>> and fix things for N CPUs. It should be possible to make the > >>>> hypervisor description file (1g2p-hv.bin) understand that CPU 1 > >>>> should > >>>> be id 1 and not 4. However, my attempt at doing so didn't seem to > >>>> work. The files required to build the hv.bin and md.bin files are > >>>> available as part of the OpenSPARC Architecture toolkit that is > >>>> available from Sun's website. The packets are generated by uncached > >>>> writes to the IOB device registers that the hypervisor code does to > >>>> get things going. > >>>> > >>>> Ali > >>>> > >>>> > >>>> > >>>> On Mar 2, 2009, at 5:29 PM, Polina Dudnik wrote: > >>>> > >>>> > >>>> > >>>>> Never mind, I started the console and got ERROR: 1 CPUs in PD did > >>>>> not start without the hack. So, you are right, there is something > >>>>> wrong with the cpu numbers. But I want to fix it for arbitrary > >>>>> numCpus. SO, to do that I want to find a place where the requests > >>>>> generate their data. So, the place where bits(12, 8) get > >>>>> generated. > >>>>> So, I guess my question is: where are the packets generated? > >>>>> > >>>>> Polina > >>>>> > >>>>> > >>>>> On Mon, Mar 2, 2009 at 3:26 PM, Polina Dudnik <pdud...@gmail.com> > >>>>> wrote: > >>>>> Hi Ali, > >>>>> > >>>>> > >>>>> Why do you say: > >>>>> > >>>>> Additionally, I had to put two hacks in to swizzle the CPU id > >>>>> numbers. For whatever reason the hypervisor insists that the > >>>>> second > >>>>> CPU should be id 4 while m5 would like it to be id 1. I tried > >>>>> changing the hypervisor description file and changing cpu4 to > >>>>> cpu1, > >>>>> however that didn't seem to change the id. > >>>>> > >>>>> > >>>>> > >>>>> What makes you think that hypervisor assigns #4 to processor #1? I > >>>>> removed this hack and everything works fine. > >>>>> > >>>>> Polina > >>>>> > >>>>> _______________________________________________ > >>>>> m5-dev mailing list > >>>>> m5-dev@m5sim.org > >>>>> http://m5sim.org/mailman/listinfo/m5-dev > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> m5-dev mailing list > >>>> m5-dev@m5sim.org > >>>> http://m5sim.org/mailman/listinfo/m5-dev > >>>> > >>>> > >>> _______________________________________________ > >>> m5-dev mailing list > >>> m5-dev@m5sim.org > >>> http://m5sim.org/mailman/listinfo/m5-dev > >>> > >>> > >> > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
