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

[Matthias Lange]

Hi Paul,

On [23-04-2018 12:23], Paul Boddie wrote:
> 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.

There is at least a path towards this. Have you had a chance to read our
contributors guide [1]? The submit and review procedures outlined there are
tailored for github, but if you like we can discuss the patches publicly on
the mailing list or privately. Just let us know.

Regarding your explanation below, I will put it on my todo list to have a look
into the Fiasco changes. But I can't promise any timeframe.

Regards,
Matthias.

[1] https://github.com/kernkonzept/fiasco/wiki/CONTRIBUTING

> 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
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

-- 
Matthias Lange, matthias.lange at kernkonzept.com, +49-351-41 888 614

Kernkonzept GmbH.  Sitz: Dresden.  Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth