Booting L4Re on the CI20: Panic in sigma0
paul at boddie.org.uk
Fri Jul 14 18:45:33 CEST 2017
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.
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
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
> 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!
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.
More information about the l4-hackers