As promised, I wrote up my experiences porting L4Re and Fiasco.OC to the Ben NanoNote:
https://blogs.fsfe.org/pboddie/?p=2147
There are, in fact, nine articles describing the process, which I accept might be a bit too much reading for the casual inquirer, especially as the narrative wanders from one problem to be solved to the next. But the summary should cover the main tasks that need to be done in this kind of work.
Since getting things working on the Ben, I have also persuaded the software to work on the Letux 400 notebook computer, which is a variant of the Skytone Alpha-400 product that did the rounds almost ten years ago (although I was probably completely unaware of it at that time):
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!
Paul
P.S. As noted before, the patches are here:
Hi Paul,
On [18-04-2018 01:34], Paul Boddie wrote:
As promised, I wrote up my experiences porting L4Re and Fiasco.OC to the Ben NanoNote:
https://blogs.fsfe.org/pboddie/?p=2147
There are, in fact, nine articles describing the process, which I accept might be a bit too much reading for the casual inquirer, especially as the narrative wanders from one problem to be solved to the next. But the summary should cover the main tasks that need to be done in this kind of work.
Since getting things working on the Ben, I have also persuaded the software to work on the Letux 400 notebook computer, which is a variant of the Skytone Alpha-400 product that did the rounds almost ten years ago (although I was probably completely unaware of it at that time):
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!
Paul
P.S. As noted before, the patches are here:
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.
Regards, Matthias
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:
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
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:
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
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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.
On Wednesday 9. May 2018 01.22.29 Paul Boddie wrote:
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.
The patches are now available in a somewhat reduced form for the three devices (Ben NanoNote, Letux 400 and MIPS Creator CI20):
http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html
I may reduce them further to avoid confusion since the patches distribution still contains things that are not required for basic support, being needed for other code that has been written...
[...]
As noted above, I have been exploring L4Re and writing code to expose hardware functions as drivers in various forms.
This work is now available here:
http://www.boddie.org.uk/paul/Landfall.html
In other threads on this list I have been exploring issues around delivering and expanding this functionality, but I suppose I have been making some progress, and it is good to separate it out from the patches against L4Re itself.
Paul
l4-hackers@os.inf.tu-dresden.de