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.