cpu/mips: Remove platform #11788
cpu/mips: Remove platform #11788
Conversation
jcarrano
added
Impact: major
jcarrano
requested review from
cladmi,
haukepetersen,
miri64,
aabadie,
maribu,
kaspar030,
MrKevinWeiss and
gschorcht
There was a problem hiding this comment.
No "dedicated" maintainer.
Looking at the copyright of some files, there are several contributors listed. So I guess these people may want to continue developing the port.
In general I think opening a PR like this without asking the initial contributors (and eventually maintainers) if they agree or not, or if they want to continue to work on the port is not the right way to go. You could also send an email to devel ML first, explaining your thoughts and wait for other contributor opinions.
That would also save you the time you already spent working on this (that you could usefully spend on other things) if there's no consensus or if the decision is to keep the support of MIPS architecture.
There was a problem hiding this comment.
For my side, I did some updates on the platform as they were required for build system changes. Not that I really needed it, other than completeness.
However I reach a point were it is really hard to know if I can do a change or not, as even with a board, you cannot run a firmware.
I was trying to maintain and test the pic32-wifire as we have one here. But note it is a board port that was merged:
- without flasher
- without uart input (no shell, no tests using input,
stdinmodule doing nothing)
My proposal to add a flasher for pic32-wifire is still waiting for one year #9259. How are we supposed to test anything without this?
It for me, does not match our current integration standards. I agree that we are in a stage where it is easier to remove the boards.
Somebody interested could immediately re-propose the port where at least, the flasher and uart input are working.
The argument about "updating the flasher with windows" is for me invalid.
Some of the other boards also need windows for configuring the flasher, update a bootloader, set a serial number. Maybe it could be done from Linux, but was faster for me to use a VM. It is just normally not documented how to do it in RIOT.
I could even remove this documentation as it is now been upstreamed to the pic32prog wiki. https://github.com/sergev/pic32prog/wiki/Using-PICkit3
|
Aside from the general MIPS issue, do you agree that the mips-malta should go? Not only is it unobtainable, it is not the kind of platform RIOT targets: it is an ATX form factor board with a chip powerful enough to run Linux. |
|
First, I presented this as a PR to make the impact of the changes in our codebase more clearly visible and also so that anyone having trouble with MIPS can pull this into their own branch. I have my own opinion, which I laid out in rather extensive commit messages. I do respect everyone else's opinions and points of view, but consider the following points:
|
|
As a contributor for pic32-wifire and pic32-pickit, I must say that I currently do not have the time to maintain the MIPS platform for RIOT-OS. I can at best help or review pull requests but I am not planning to write more code for MIPS. I am not against removing support for the MIPS malta board, I never worked on it. @cladmi It seems I missed #9259. Sorry ! |
|
I would like to remove the malta board at least. I think the first effort should be at removing the boards that are obsolete such as ones that cannot be purchased anymore or are clearly not a good candidate for RIOT. The fact is we can give the wifire and clicker some love (I have the boards) and get the flasher going since there is a PR #9259. From the marketing point of view it is still nice to say we support it (assuming we actually support it). From the maintainability cost point of view, if we can get it up to the point where it can go in the on-target test rack (ie paper-ci) and the hardware assisted ci (ie PHiLIP) there would only be the maintenance of keeping it up to date (such as porting any api change or blacklists), which is some work but doable considering what we get. This would have an advantage of distributed workload rather than someone having to update everything at once. Maybe we say we start to deprecate it and if nothing has been done to get it up to what the minimum RIOT standard should be then we remove it (that is 6 months or so). That being said, maybe with some reviewing help from @francois-berder and some prs from @cladmi I could help push the rest though. Since I have an interest on getting it in my HiL setup I am willing to give it some love (though I don't want to be responsible fully for it as just the openmote-b has cost me about 30 hours debugging and adding hacks due to poor documentation and questionable board design decisions). tldr; |
jcarrano
added
the
State: waiting for other PR
|
I placed the "Waiting" label, as this needs deprecation notices before it can move forward. @francois-berder Thanks for your insights (and for the contributions).
That's what I'm looking for with this PR. Not just a "let's keep it" but rather "I'll fix it so we can keep it". HiL is your project and you do as you see fit. My personal opinion is that you would be adding more value by making popular boards run better, improving documentation and polishing the system than by incorporating these boards. |
|
Just to be clear I would like to remove the malta board and shift the conversation to any other boards to remove. |
|
For information about the current state of Even if it is reported as Since And such even in our CI https://ci.riot-os.org/RIOT-OS/RIOT/master/6b094a78a943bcbd74d21a7ce83840c1fdcdc0a6/output/compile/tests/minimal/mips-malta:gnu.txt When the inconsistency of using a different dependencies resolution in |
The mips-malta board is a maintainance burden, has no working UART input
and is unobtainable and thus must be removed.
1. Unobtainable board
=====================
The mips-malta board is not an off-the-shelf part. A quick web
search only show the MIPS website where one is told to "contact sales".
I could find it on ebay, used, at €155 and from single seller.
Not having access to the board means:
a. We cannot maintain it. In fact it could be broken right now.
b. Potential RIOT uses have not access to the board either. In other
words, it is pointless to run on hardware nobody has.
2. No working UART input
========================
Not all applications need UART input, but that is no excuse for not supporting
it:
a. Makes development & debugging way harder.
b. It is impossible to run interactive tests.
b.1. Constrains the rest of the platforms by providing an incentive to not
make tests interactive.
c. The lack of UART is a witness to the poor quality of the port.
I want to stress point (c). If something as basic as a serial port cannot work,
how can we expect more complex fucntionality to work. The answer is impossible
to know, because of point (1).
3. Maintainance burden
======================
The RIOT project has limited time and human resources which can be better spent.
a. Compiling for mips-malta wastes CPU time.
b. Blacklisting the board in the test wastes contributor's time.
c. Adapting the board's makefile during build system rework takes time and makes
the reworks harder.
c.1. Add to that that the changes are most of the time not even tested on the board
because of (1). Look at the github issues/PRs and you will see it.
d. Developers usually stick to the lowest common denominator. Issue (2) sets this
denominator unacceptably low.
MIPS platform in general
========================
In commits I will address general issues in the MIPS platform and why it should all
be removed.
Note: in contrast to mips-malta, these boards are still available for purchase.
This means that if the issued listed below were to be fixed (and the boards
maintained by a person versed in the architecture) then adding them back
would be a valid possibility.
The pic32-clicker and pic32-wifire have severe issues affecting their usability,
maintainability and have no maintainer.
1. Usability
============
I doubt the current implementation of these board can be use for any serious
development.
This is a problem with MIPS-RIOT integration in general and was explained in the
PR removing mips-malta:
> a. Makes development & debugging way harder.
> b. It is impossible to run interactive tests.
> b.1. Constrains the rest of the platforms by providing an incentive to not
> make tests interactive.
> c. The lack of UART is a witness to the poor quality of the port.
This alone should have been enough reson not to merge this boards in the first place.
pic32-wifire is the least worse. At least it can be flashed from Linux, though it
is not an easy task. From dist/tools/pic32prog/doc.md
>It will require flashing a specific firmware on the PICkit3.
> As this can only be done from a Windows computer, that not many Linux users
> have, the following steps explain how to setup a Windows VirtualBox virtual
> machine and flash the PICkit3 from it.
>
> Informations come from this comment
>
> RIOT-OS#6092 (comment)
pic32-clicker HAS NO FLASHER and requires one to use MPLAB.
2. No maintainer
================
There is no (active) RIOT maintainer with deep knowledge of the boards and
platform. A quick search through the issues and PRs shows this.
3. Maintainability
==================
As a consequence of (1) and (2) many tests are not run in these boards. At the
same time, RIOT maintainers - especially those working on the build system - still
have to modify and migrate mips-foo boards.
The rest of the arguments here are the same as presented with the mips-malta
removal.
This removal does not mean MIPS is banished from RIOT until the end of times. As I explain below, many of the problems stem from the lack of dedicated maintainers for the platform. I do not think that MIPS is orders of magnitude more complex than other plaforms (maybe it is, but I don't know). The thing is, the other plaforms have people working every day to iron out the bugs. If such a thing were to happen to MIPS, it could go back into RIOT. Until that happens, though we cannot afford to support it. 1. Were we really supporting MIPS? Or, what is lost? ==================================================== Support for the MIPS platform was never complete. Two of the most important featues used in RIOT develoment are still missing: UART input and flasher support. In addition, the platform has no maintainer and nobody working to improve it (aside from some work from @cladmi, but he is not expert in the platform). This, and the fact that there is nobody frequently testing it means a bit portion of the port may be broken right now. This alone is a major pain. For our users it means the plaftorm is of dubious value. For us developers it introduces more inefficiencies in our work: - We try to keep the testing infraestructure runnable on all boards. This means we target the lowest commond denominator. A platform without UART really lowers this bar. - It is holding back the introduction of deeper and harder interactive tests. - No flasher means it is not possible to automatically run all the test suite. - I'm repeating myself, see the previous commit messages. The MIPS platform does not have a maintainer. While there is no such thing as "official plaform maintainer" in RIOT, in reality there are de-facto maintainers for all the "well supported" platforms. These are people with good knowledge of the architecture, access to boards and active in the community. These are the persons one can rely upon to test PRs and ensure the platform keeps working. See for example the SAM and the STM32 plaforms. MIPS is lacking such a maintainer. 2. MIPS microcontrollers are dead ================================= (Please note that I'm NOT referring to the architecture in general, which is still in use in other applications) I'm sure that from a technical point of view, MIPS may have some advantages. Technilogical history shows, however, that it is not the best technicals solutions that triumph. The determining factor is economics. A smaller platform means more lock-in, less tooling support, less software availability. A quick looks at current offerings of MIPS MCUs shows only Microchips products are practically available. Now, Microchip has bought Atmel and its line of SAM Arm MCUs. I would not be surprised if in a few years they decided to discontinue (or "not recommended to new designs") their MIPS line.
Now that MIPS is gone, the ifdef is no longer necessary. If it eve gets added back in we should think of a more elegant way to integrate it with the C library.
The `mips32r2_generic` CPU was only used by the `mips-malta` board which has been removed. The reasons for this removal are the same as for the board: - No hardware to test. - The board that used this CPU is not available off the shelf. - No UART input. - No integrated flasher (one needs to use a separate Windows tool) For more information and discussion around MIPS, see issues: - RIOT-OS#11831 (Removal of mips-malta) - RIOT-OS#11788 (General MIPS removal)
The `mips32r2_generic` CPU was only used by the `mips-malta` board which has been removed. The reasons for this removal are the same as for the board: - No hardware to test. - The board that used this CPU is not available off the shelf. - No UART input. - No integrated flasher (one needs to use a separate Windows tool) For more information and discussion around MIPS, see issues: - RIOT-OS#11831 (Removal of mips-malta) - RIOT-OS#11788 (General MIPS removal)
|
With the recent activity around MIPS boards, I think this can be closed now. |
|
The last time I checked, the |
|
Since there is still work done on this platform by @francois-berder, I'm closing this one. The failures reported will probably be fixed with #13094, so just a matter of time. |
Note: before removal there should be a deprecation. I open this PR so that we can discuss the removal itself.
Note 2: The following text is a copy-pasta of the commit messages, so you can read those instead.
Before we start...
...this removal does not mean MIPS is banished from RIOT until the end of times. As I explain below, many of the problems stem from the lack of dedicated maintainers for the platform.
I do not think that MIPS is orders of magnitude more complex than other plaforms (maybe it is, but I don't know). The thing is, the other plaforms have people working every day to iron out the bugs. If such a thing were to happen to MIPS, it could go back into RIOT. Until that happens, though we cannot afford to support it.
Reasons to remove MIPS (or, What's wrong?)
No "dedicated" maintainer.
The MIPS platform does not have a maintainer. While there is no such thing as "official plaform maintainer" in RIOT, in reality there are de-facto maintainers for all the "well supported" platforms. These are people with good knowledge of the architecture, access to boards and active in the community.
These are the persons one can rely upon to test PRs and ensure the platform keeps working. See for example the SAM and the STM32 plaforms.
MIPS is lacking such a maintainer.
Poor usability
I doubt the current implementation of these board can be use for any serious development.
No working UART input
a. Makes development & debugging way harder.
b. It is impossible to run interactive tests.
b.1. Constrains the rest of the platforms by providing an incentive to not
make tests interactive.
c. The lack of UART is a witness to the poor quality of the port.
I want to stress point (c). If something as basic as a serial port cannot work,
how can we expect more complex fucntionality to work. The answer is impossible
to know, because of point (1).
No flasher
pic32-wifire is the least worse. At least it can be flashed from Linux, though it
is not an easy task. From dist/tools/pic32prog/doc.md
pic32-clicker HAS NO FLASHER and requires one to use MPLAB.
Maintainance burden
The RIOT project has limited time and human resources which can be better spent.
a. Compiling for these boards wastes CPU time.
b. Blacklisting the boards in the test wastes contributor's time.
c. Adapting the board's makefile during build system rework takes time and makes
the reworks harder.
c.1. Add to that that the changes are most of the time not even tested on the board
because of lack of people with the board (and no flasher). Look at the github issues/PRs and you will see it.
d. Developers usually stick to the lowest common denominator. No UART input and no flasher sets this
denominator unacceptably low.
MIPS microcontrollers are dead
(Please note that I'm NOT referring to the architecture in general, whichis still in use in other applications)
I'm sure that from a technical point of view, MIPS may have some advantages. Technilogical history shows, however, that it is not the best technicals solutions that triumph. The determining factor is economics.
A smaller platform means more lock-in, less tooling support, less software availability.
A quick looks at current offerings of MIPS MCUs shows only Microchips products are practically available. Now, Microchip has bought Atmel and its line of SAM Arm MCUs. I would not be surprised if in a few years they decided to discontinue (or "not recommended to new designs") their MIPS line.
Testing procedure
I need a bit of help here. What could I have broken?
Issues/PRs references
(TODO)