Re: Activating the sigma0 thread in the Fiasco kernel

On Thu Mar 08, 2018 at 00:52:55 +0100, Paul Boddie wrote:
> 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. :-)

Good!


Adam