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
