Booting L4Re on the CI20: Panic in sigma0

[Paul Boddie]

On Friday 14. July 2017 17.39.15 Sarah Hoffmann wrote:
> 
> > The problem here is that the .cpload directive (operating on t9/$25)
> > doesn't have a known value of t9 to work with, it would seem.
> > Consequently, the calculations in the generated code work with a value
> > that isn't initialised.
> 
> This suspiciously looks like a compiler issue. I would .cpload expect to
> translate to a nop on mips32r2 without PIC.

I thought sigma0 was compiled as position-independent code, though. Or is it 
the case that it should not be compiled in that way and that gcc is just 
pursuing its usual strategy.

> We generally use the compilers provided by Imagination(*). The Debian GCC
> might do things slightly differently, I need to check that again. Making the
> code work with the official GCC is on our list, although not very high at
> the moment. If you can switch to the Imgtec GCC for the moment, this might
> save you some headache.
> 
> (*)
> http://community.imgtec.com/developers/mips/tools/codescape-mips-sdk/downlo
> ad-codescape-mips-sdk-essentials/

I would much rather stick with gcc and not have to install vendor-specific 
tools. Moreover, since gcc appears to be the recommended compiler for L4Re in 
general, it seems like restoring support for it would do a lot to eliminate 
such surprises.

So perhaps I can try and get the code to work with gcc, if that would be 
helpful to your efforts. I imagine that it would also be beneficial to a wider 
audience.

[CI20 support]

> It won't be that easy I'm afraid. Last time we tried the board, we found
> that the CI20 has a crippled instruction set. In particular, it does not
> support the rdhwr instruction which L4Re user programs use to clean
> caches. The easiest way to work around this issue by emulating the
> instruction in Fiasco. There is already some code for catching rdhwr.
> Look for "ENTRY reserved_insn" in src/kern/mips/exception.S. Somebody
> 'just' needs to add support for reading the cache configuration values.

I'll admit to not being familiar with the different MIPS ISA versions, nor 
particularly with the MIPS instruction set in general. I have been able to 
write MIPS assembly language programs doing a variety of things, but I don't 
profess to be an expert.

From what I've seen of code for other Ingenic SoCs, particularly those which 
didn't claim MIPS compliance, it wouldn't surprise me if there were some 
deviations from what people might expect from other MIPS products. That said, 
such SoCs are supported by other operating system projects, so I imagine it is 
"just" a matter of filling in the gaps, as you say.

It does also interest me to try and get L4Re working on the jz4720 in the Ben 
NanoNote, if only because it should be possible, but that would probably also 
demand the trapping of floating point instructions. But such things are 
already being done elsewhere, so it's "just" a matter of filling this in, too.

Is there anything else I should be aware of? I saw that Kernkonzept had done 
work with Imagination on MIPS support, but I get the impression that this 
ultimately didn't cover the CI20. Is this a reasonable impression?

Thanks for replying to my previous message!

Paul

P.S. On the topic of vendor tools, I have had some recent experiences with 
Microchip's MIPS-based products, and the culture of reliance on Microchip's 
developer tools - even if some of them might actually be based on the GNU 
tools - is a rather irritating and frustrating thing, both for people trying 
to figure out the operation of the silicon as well as those who have made 
themselves dependent on those tools.