S1 Core
In the S1 Core environment the predefined test, after a few instructions, just executes a series of NOP instructions.<br> But if you take a memory image from a real case (an OpenSPARC T1 test) after the first instructions the SPARC Core sends a dirty request and hangs.<br> If you want to see the problem, just run the following command once and then run again the simulation:<br> <b>mv -f $S1_ROOT/tests/boot/mem_RED_EXT_SEC.image_ORIGINAL $S1_ROOT/tests/boot/mem_RED_EXT_SEC.image</b><br> To see exactly which instruction cause the trouble look into the file <b>$S1_ROOT/docs/other/ACCESSES.txt</b> that you can also see online at <b> http://www.opencores.org/cvsweb.shtml/s1_core/docs/other/ACCESSES.txt?rev=1.2;content-type=text%2Fx-cvsweb-markup </b> <br> To obtain the informations detailed in this file I had to disassemble the memory image using a new tool that you can find into <b>$S1_ROOT/tools/opt/disass</b>, and I have compared the resulting waveforms against the T1 ones using another tool, placed in <b>$S1_ROOT/tools/opt/tracan</b>.<br> There could be several reasons why the SPARC Core hangs:
<ol> <li>these instructions (coming presumably from the OpenBoot PROM code) are not appropriate for this SPARC Core inside the S1; <li>in the original T1 waveforms some fetch cause a L2 Instruction Cache Miss, while in this environment it does never happen since there's no L2 cache; it is possible that the SPARC Core require some of them; <li>the S1 Core environment applies a patch to the original SPARC Core source code to add an external stall signal, to avoid the core sending another request when there's a pending one (the spc2wbm core has no FIFOs); maybe this has been done in the wrong way. </ol> If you are a software expert, you <b>(YOU!)</b> could probably help with point 1), i.e. you could tell me what do the first assembly instruction mean and what they are supposed to find into the processor.A guess.
Since T1 have lots of things S1 does not have. It could be that the code tries to configure things like cache controler, ... But since there is no unit to accept these writes they might hang as soon as the write buffer is filled up (earlier code might have configured that they do exist!)
If possible you should configure and compile the OpenBoot PROM exactly for the environment were it will run. (Later you might stumble into RAM memory configuration)
The source for the boot code shown in the linked file can be found inside the official OpenSPARC T1 tarball, in the file: $T1_ROOT/verif/diag/assembly/include/hred_reset_handler.s
I've been looking into the boot code, and I'm pretty sure that there's just a configuration issue; being a software issue I'm going to move the design status from Beta to Stable.
As I told before it was just a software problem; if I remove the following stores to Interrupt Queues Registers the test is executed normally:
0000040100: c0 f0 23 c0 stxa %g0, 0x3c0 %asi 0000040104: c0 f0 23 c8 stxa %g0, 0x3c8 %asi 0000040108: c0 f0 23 d0 stxa %g0, 0x3d0 %asi 000004010c: c0 f0 23 d8 stxa %g0, 0x3d8 %asi 0000040110: c0 f0 23 e0 stxa %g0, 0x3e0 %asi 0000040114: c0 f0 23 e8 stxa %g0, 0x3e8 %asi 0000040118: c0 f0 23 f0 stxa %g0, 0x3f0 %asi 000004011c: c0 f0 23 f8 stxa %g0, 0x3f8 %asi