A new post titled "[GSoC] Better RISC-V support, week #3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/13/gsoc-better-risc-v-support-week-3/

<p>Last week, after updating GCC (by applying <a href="https://review.coreboot.org/#/c/14604/">Iru Cai’s patch</a>) and commenting out uses of outdated instructions and CSRs (most notably <tt>eret</tt> and the HTIF CSRs), I noticed that coreboot crashed when it tried to access any global variables. This was because the coreboot build system thought coreboot would live near the start of the address space.</p>
<p>I found <tt>spike-riscv/memlayout.ld</tt>, and <a href="https://review.coreboot.org/#/c/15149/1/src/mainboard/emulation/spike-riscv/memlayout.ld">adjusted the starting offset</a>. But then I got a linker error:<br />
<code><br />
build/bootblock/arch/riscv/rom_media.o: In function `boot_device_ro': [...]/src/arch/riscv/rom_media.c:26:(.text.boot_device_ro+0x0): relocation truncated to fit: _RISCV_HI20 against `.LANCHOR0'<br />
</code></p>
<p>I played around with the start address and noticed that addresses below <tt>0x78000000</tt> worked, but if I chose an address that was too close to <tt>0x80000000</tt>, it broke. This is, in fact, because pointers to global variables were determined with an instruction sequence like <tt>lui a0, 0xNNNNN; addi a0, a0, 0xNNN</tt>. On 32-bit RISC-V, the LUI instruction loads its argument into the upper 20 bits of a register, and ADDI adds a 12-bit number. On a 64-bit RISC-V system, <tt>lui a0, 0x80000</tt> loads <tt>0xffffffff80000000</tt> into <tt>a0</tt>, because the number is <a href="https://en.wikipedia.org/wiki/Sign_extension">sign extended</a>.</p>
<p>After disassembling some <tt>.o</tt> files of coreboot and the <a href="https://github.com/riscv/riscv-pk">RISC-V proxy kernel</a>, I finally noticed that I had to <a href="https://review.coreboot.org/#/c/15148/1">use the <tt>-mcmodel=medany</tt> compiler option</a>, which makes data accesses pc-relative.</p>
<p>Now that coreboot finally ran and could access its data section, I finished debugging the <a href="https://github.com/riscv/riscv-isa-sim/pull/53">UART block</a> that I promised last week. Coreboot can now print stuff, but it stops running pretty soon.</p>
<p><b>Plans for this week</b></p>
<p>This week I will debug why coreboot hangs, and will hopefully get it to boot until the “Payload not found” line again, which worked with an older version of Spike.</p>
<p>Also, Ron Minnich will be giving a talk about coreboot on RISC-V at the coreboot convention in San Francisco, <a href="https://calendar.google.com/calendar/event?eid=cWxhOXZnYWI5cmZoNW0zY2gwcTRvZ3Zxc2dfMjAxNjA2MTNUMTg0NTAwWiA2YjF1OGlxMTNqajhjcDZrZm9rcTR2bG8yMEBn">in a few hours</a>.</p>