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

On Thursday 26. April 2018 08.23.21 Matthias Lange wrote:

On [23-04-2018 12:23], Paul Boddie wrote:

...

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.

Sorry to be so slow in replying to this! I have actually been trying to do some more work with L4Re and this has kept me distracted from getting back to this particular topic. (I wonder whether there is much scope for discussion about L4Re on this list because it seems very quiet and not much is said about L4Re even when there are messages.) My aim will be to distill the patches to the essentials to support these systems in Fiasco.OC and L4Re. I think that some of the patch files more or less encapsulate these essential changes (those having the topics "fiasco", "l4re" and "platform"). As noted earlier, I am not really sure about the form of some of the changes, but I guess things can be redone appropriately. In general, I am not very enthusiastic about signing agreements with entities where I get to relinquish various rights or privileges. Ideally, I would just license my changes using the same licence as the work and then contribute them. Failing that, I would rather permissively license my changes and they would then be taken up in the upstream code. But at the same time I understand that it is rather difficult to formulate permissively-licensed patches on a copyleft-licensed project [*] and, contrary to popular belief, there are still obligations when incorporating permissively-licensed work. However, given that most of my changes have little originality, some being copy-and-paste additions based on existing code in the sources, I imagine that I could effectively submit them in a CC0-equivalent form and pretend that the maintainers did the extra work to support these systems themselves. This includes the CI20-related changes which are practically trivial. As noted above, I have been exploring L4Re and writing code to expose hardware functions as drivers in various forms. I intend to make this available in a more convenient form later, and I will be licensing my own contributions to it under the GPL version 2 or later. Since some things arguably borrow from some L4Re code, I imagine that the result may only be GPL version 2 only, unless we wave away such similarities. It is unfortunate that a strict licence version policy has been chosen, but I guess that may have been decided by the lawyers. I will try and look at the contributor documentation again. Thanks for following up on this and apologies once again for being slow to respond! Paul [*] I am aware that the GPL permits modifications where those modifications are permissively licensed, provided that the licensing is GPL-compatible. However, it gets a bit difficult to put the necessary boilerplate on some patches. I imagine that this would really involve me publishing complete files or even complete sources with the necessary boilerplate included somewhere.