Booting L4Re on the CI20: Panic in sigma0

[Paul Boddie]

On Tuesday 18. July 2017 08.58.14 Sarah Hoffmann wrote:
> 
> There is a bug in the Fiasco where it sends the wrong message size.
> Please apply the attached patch to Fiasco. Afterwards you should get
> more useful error messages in your L4 applications when it throws
> exceptions.

Yes, this fixes the recurring failure to handle the page fault successfully. 
Thanks for sending this!

[...]

> An address error generally means that you are trying to access a bad
> address (which would be the case with the PFA given above). This is
> different from a normal page fault, which corresponds to TLB exceptions.
> That is why sigma0 is not involved.

Right. I appreciate the clarification here.

> Exceptions are directly sent to the exception handler which in a
> standard L4 application is the thread started first (l4re-kernel thread)
> or, if that one fails, the launcher (moe in your case).

Yes, this is what I might have expected.

[...]

> The t9 issue is a likely cause. There are a couple of places where
> .cpload is used.

I found another location where t9 is not initialised:

pkg/l4re-core/l4re_kernel/server/src/ARCH-mips/loader_mips.S

I had actually seen this, but I guess I was distracted too much with the other 
problems to realise that it needed changing.

So, I applied the Fiasco patch and then looked at the above file, checking the 
objdump output for the l4re binary. With the patch applied, the page fault did 
not occur endlessly, and with a change to the above file similar to those 
already made for sigma0 and moe, it appears that the page fault is eliminated 
completely. As a consequence, the "hello" example now runs, finally!

I have attached a few patches required to make this happen in my 32-bit Intel, 
Debian-based mipsel-linux-gnu development environment:

ci20-gcc-cpload.diff  Initialises t9 for .cpload
ci20-gcc-debian.diff  Uses the mipsel-linux-gnu toolchain prefix
ci20-rdhwr.diff       Implements rdhwr SYNCI_Step handling
ci20-uart0.diff       Uses the UART0 connection to work around UART4 problems
no-at.diff            A missing definition (mentioned previously on this list)

The rdhwr patch could probably be improved, and I think there are places in 
the affected file where common code could be consolidated a bit more.

I appreciate the help and guidance you have provided in getting me to this 
point, and I hope now to try and test the drivers that I had written in 
advance of getting the examples working.

Thanks once again,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ci20-gcc-cpload.diff
Type: text/x-patch
Size: 1541 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170718/4954e369/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ci20-gcc-debian.diff
Type: text/x-patch
Size: 904 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170718/4954e369/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ci20-rdhwr.diff
Type: text/x-patch
Size: 3752 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170718/4954e369/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ci20-uart0.diff
Type: text/x-patch
Size: 811 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170718/4954e369/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-at.diff
Type: text/x-patch
Size: 375 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170718/4954e369/attachment-0004.bin>