Porting L4Re and Fiasco.OC to the Ben NanoNote and Letux 400

[Paul Boddie]

On Monday 23. April 2018 09.54.55 Matthias Lange wrote:
> 
> On [18-04-2018 01:34], Paul Boddie wrote:
> > 
> > http://blogs.fsfe.org/pboddie/?p=2175
> > 
> > I hope that some of the information I have shared is useful to others and
> > perhaps encourages someone else to port the software to a device of their
> > choosing. Good luck to that person!
> 
> Nice work you have done there!

Thanks! There was a bit of a learning process, but the second exercise was a 
lot easier than the first.

> > P.S. As noted before, the patches are here:
> > 
> > http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html
> 
> Maybe you would like to fork from our github releases [1] and upload your
> patches there as well? I think this would make is more discoverable to more
> people.

I don't have a GitHub account, but I did wonder whether the content of my 
patches would be acceptable as currently formulated.

To support the architecture variant, I introduce places where I test for a 
configuration setting called CONFIG_CPU_MIPS32_R1. In some places this is to 
disable tests that presumably acknowledge that older architecture versions 
wouldn't work with the code as it was. For example (from src/kern/mips/cpu-
mips.cpp):

#ifndef CONFIG_CPU_MIPS32_R1
  require(c.r<0>().ar() > 0,  "MIPS r1 CPUs are notsupported\n");
#endif

This is followed by tests for configuration registers that would otherwise be 
used. Meanwhile, in other places such tests change the instructions employed. 
For example (from src/kern/mips/alternatives.cpp):

#ifdef CONFIG_CPU_MIPS32_R1
    asm volatile ("cache 0x01, %0\n"
                  "nop\n"
                  "cache 0x08, %0"
                  : : "R"(orig_insn[i]));
#else
    asm volatile ("synci %0" : : "R"(orig_insn[i]));
#endif

This example being mentioned in one of my articles:

http://blogs.fsfe.org/pboddie/?p=2006

I am guessing that it is not particularly desirable to have lots of #ifdefs in 
the code because it makes things messy and harder to maintain. So I wondered 
if better mechanisms are available for doing these kinds of things.

Another place with significant changes is the src/kern/mips/exception.S file, 
employing macros for instructions that are not available on the earlier 
JZ4700-series devices (and probably not in MIPS32r1). Again, it occurs to me 
that these things might be handled in a slightly cleaner way, but it was more 
important to get the code working. And the exception.S file is the location of 
the rdhwr changes that also apply to the CI20.

Anyway, I thought I'd get some opinions on the way I've done some of this 
before considering submitting anything. Thanks for responding to my earlier 
message!

Paul

> [1] https://github.com/kernkonzept