A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #9 #10" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/25/gsoc-coreboot-for-arm64-qemu-week-9-10/
<p>In the last post I talked about using aarch64-linux-gnu-gdb and debugging in qemu. In these two weeks I was intensely involved in stepping through gdb, disassembly and in-turn debugging the qemu port. I summarise the major highlights below.</p>
<p>Firstly, the correct instruction to invoke qemu is as follows</p>
<pre>./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 2048 -bios ~/coreboot/build coreboot.rom -s -S</pre>
<p>After invoking gdb, I moved onto tracing the execution of the instructions step by step to determine where and how the code fails. A compendium of the code execution is as follows</p>
<blockquote>
<div>gdb) target remote :1234</div>
<div>Remote debugging using :1234</div>
<div>
<div>(gdb) set disassemble-next-line on</div>
<div>(gdb) stepi</div>
<div>0x0000000000000980 in ?? ()</div>
<div>=> 0x0000000000000980: 02 00 00 14 b 0x988</div>
<div>(gdb)</div>
<div>0x0000000000000988 in ?? ()</div>
<div>=> 0x0000000000000988: 1a 00 80 d2 mov x26, #0x0 // #0</div>
<div>(gdb)</div>
<div>0x000000000000098c in ?? ()</div>
<div>=> 0x000000000000098c: 02 00 00 14 b 0x994</div>
<div>
<div>(gdb) c</div>
<div>Continuing.</div>
<div>^C</div>
<div>Program received signal SIGINT, Interrupt.</div>
<div>0x0000000000000750 in ?? ()</div>
<div>=> 0x0000000000000750: 3f 08 00 71 cmp w1, #0x2</div>
</div>
</div>
</blockquote>
<p>The detailed version can be seen <a href="http://pastebin.com/EPM6RkYA">here</a>.</p>
<p>The first sign of error can be seen here, where the instruction is 0 and the address is way off.</p>
<pre><span style="font-family: 'Noto Serif', serif;line-height: 1.6471">0x64672d3337303031 in ?? ()
=> 0x64672d3337303031: 00 00 00 00 .inst 0x00000000 ; undefined</span></pre>
<p>To find insights as to why this is happening, I resorted to tracing in gdb. This can be done by adding the following in the qemu invoke command. This creates a log file in /tmp which can be read to determine suitable information.</p>
<pre>-d out_asm,in_asm,exec,cpu,int,guest_errors -D /tmp/qemu.log</pre>
<p>Looking at the disassembly, it can be seen that execution of instructions till 0x784 is correct and it goes bonkers immediately after it. Looking at the <a href="http://pastebin.com/qRkic9QM">trace</a>, this is where the code hangs</p>
<blockquote>
<div>
<div>IN:</div>
<div>0x0000000000000784: d65f03c0 ret</div>
</div>
</blockquote>
<div>The ret goes to somewhere bad. So the stack has been blown or it has executed into an area it should have prior to this. Next, I did a objdump on the bootblock.debug file. Relating to the code at this address, it could be determined that the code fails at “ret in 0000000000010758 <raw_write_sctlr>:”</div>
<div>Next up was determining where the stack gets blown or corrupt. For this, while stepping through each instruction, I looked at the stack pointer. The output <a href="http://pastebin.com/5mXGmfZx">here </a>shows the details. Everything seems to function correctly till 0x00000000000007a0 (0x00000000000007a0: f3 7b 40 a9 ldp x19, x30, [sp] ), then next is 0x00000000000007a4: ff 43 00 91 add sp, sp, #0x10 . This is where saved pc goes corrupt. This code gets called in the “raw_write_sctlr_current” (using objdump)</div>
<div></div>
<div>From the trace, we have the following information : The ret goes bad at 0000000000010758 <raw_write_sctlr>:</div>
<div>
<blockquote>
<div>0x0000000000000908: 97fffe06 bl #-0x7e8 (addr 0x120)</div>
<div>
<div>…</div>
<div>0x0000000000000120: 3800a017 sturb w23, [x0, #10]</div>
<div>0x0000000000000124: 001c00d5 unallocated (Unallocated)</div>
</div>
<div>…</div>
</blockquote>
<div>
<blockquote>
<div>Taking exception 1 [Undefined Instruction]</div>
<div>…from EL1</div>
<div>…with ESR 0x2000000</div>
</blockquote>
</div>
<div>Which is here:</div>
<div>
<blockquote>
<div>0000000000010908 <arm64_c_environment>:</div>
<div> 10908: 97fffe06 bl 10120 <loop3_csw+0x1b></div>
<div> 1090c: aa0003f8 mov x24, x0</div>
</blockquote>
</div>
</div>
<div>
<div>This finally gave some leads in the qemu debug. There seems be some misalignment in smp_processor_id.</div>
<div></div>
<div>While tracing in gdb, we have</div>
<div>
<div>0x0000000000000908 in ?? ()</div>
<div>=> 0x0000000000000908: 06 fe ff 97 bl 0x120</div>
</div>
<div></div>
<div>(which is actually bl smp_processor_id (from src/arch/arm64/stage_entry.S))</div>
<div></div>
<div>
<div>
<div>Under arm64_c_environment (in objdump) we have;<br />
10908: 97fffe06 bl 10120 <loop3_csw+0x1b></div>
<div>Also in the trace we have<br />
IN:<br />
0x0000000000000908: 97fffe06 bl #-0x7e8 (addr 0x120)</div>
<div></div>
<p>Now loop3_csw is defined at (from objdump)<br />
0000000000010105 <loop3_csw>:</p>
</div>
<div>So this + 0x1b = 10120</p>
<p>Thus it wants to branch and link to 0x120 but smp_processor_id is at 121.</p></div>
<div></div>
<p>smp_processor_id is at (from objdump)<br />
0000000000010121 <smp_processor_id>:</p></div>
</div>
<div></div>
<div>This gives us where the code is failing. Next up is finding out the reason for this misalignment and rectifying it.</div>
<div>
<div></div>
</div>
<p> </p>
<p> </p>
<p> </p>