Activating the sigma0 thread in the Fiasco kernel

[Paul Boddie]

On Wednesday 7. March 2018 01.22.46 Paul Boddie wrote:
> 
> Currently, I have reason to believe that an exception occurs causing the
> sigma0 thread to terminate, but it's getting late and my debugging
> efficiency is suffering. I think that when the thread terminates, it has
> the following cause register flags set:
> 
> ExcCode = 0b01101 (= 11, coprocessor unusable)
> IP2 = 1
> CE = 0b01
> 
> The error exception program counter seems to be given as 0x80210000, which
> doesn't sound consistent with a user mode address, but perhaps the kernel
> is using that register for something else.
> 
> So maybe there's some FPU stuff that I haven't managed to eradicate in the
> L4Re code.

None of this appeared to be accurate, probably because I was reading directly 
from the cause register when I should have been reading the saved version. 
Anyway, I decided to make the kernel stop upon receiving the first thread-
halting condition, and this yielded the following details:

* Stored cause has ExcCode 4 (address error, load/instruction fetch)
* Stored exception program counter is 0x2092ac
* Stored bad virtual address is 0xfff2aff4

In sigma0, I found the following rather interesting, produced using objdump 
with some comments added by me:

  209290:       3c02fff3        lui     v0,0xfff3
  209294:       24422000        addiu   v0,v0,8192    // 0xfff32000
  209298:       afc2011c        sw      v0,284(s8)
  20929c:       7c02e83b        0x7c02e83b            // rdhwr v0, $29 (ULR)
  2092a0:       afc20118        sw      v0,280(s8)
  2092a4:       8fc20118        lw      v0,280(s8)
  2092a8:       8fc30158        lw      v1,344(s8)
  2092ac:       8c508ff4        lw      s0,-28684(v0) // 0xfff2aff4

Evidently, v0 was not getting updated by the rdhwr instruction, which should 
be handled as a reserved instruction. Thus, the previous value of v0 was being 
combined with the offset in the final instruction above, causing a read from a 
completely invalid address that happens to feature in the saved bad virtual 
address register.

So, I had a look at my code and discovered that I had indeed transcribed an 
operation incorrectly: it was related to implementing the ins instruction for 
this SoC; I had employed the wrong temporary register and was losing the 
original instruction details when attempting to get the target register.

At this point, I think Fiasco now starts up. However, I now need to figure out 
how to perform the necessary operations to reinitialise the framebuffer and do 
interesting things like provide feedback on what is actually going on in my 
example programs. I hope it gets a bit easier from this point, though. :-)

Paul