Porting L4Re and Fiasco.OC to the Ben NanoNote and Letux 400
paul at boddie.org.uk
Mon Apr 23 12:23:50 CEST 2018
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  and upload your
> patches there as well? I think this would make is more discoverable to more
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-
require(c.r<0>().ar() > 0, "MIPS r1 CPUs are notsupported\n");
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):
asm volatile ("cache 0x01, %0\n"
"cache 0x08, %0"
: : "R"(orig_insn[i]));
asm volatile ("synci %0" : : "R"(orig_insn[i]));
This example being mentioned in one of my articles:
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
>  https://github.com/kernkonzept
More information about the l4-hackers