Planned obsolete mips support removal
ClosedPublic
Actions

Authored by imp on Dec 13 2018, 7:58 PM.

Details

Reviewers

Commits

rS342258: Remove old config file for SENTRY5
rS342257: Remove support for running 32-bit kernels on 64-bit hardware.
rS342256: Remove the GXEMUL support.
rS342255: Remove support for the now very old SiByte MIPS platform. It's not

Summary

Remove support for the now very old SiByte MIPS platform. It's not
relevant and is unused. It's also getting in the way of progress in
some admittedly minor ways. Better to retire it to reduce the burden
on the project.

Remove the GXEMUL support.

gxemul was a nice stop-gap while qemu support for mips was firmed
up. Now MALTA* + qemu is the platform of choice retire gxemul support.
It's unknown when this was last confirmed working.

Remove support for running 32-bit kernels on 64-bit hardware.

This was useful in bring up. However, it causes more issues than the
support is worth (64-bit atomics being chief among them).

Remove partial support for old atheros AR531x.

The AR531x cores implement the mips32 ISA. The new minimum for
FreeBSD's 32-bit mips port is mips32r2. In addition, this support
wasn't completely connected to the build, and appears to have been
disconnected for some time. This hardware is too old to be relevant
(greater than 10 years) and too slow to be worth the hassles (180MHz).

Remove support for Realtek RT2880

This is a 10-year-old part that implements only the mips32 ISA. 32-bit
FreeBSD/mips now requires mips32r2 or better. Some support for the SoC
and different devices remains since I was unsure what might be used in
newer designs. This part is too slow (266MHz) and too small (systems
<= 64MB) to be interesting enough to be worth the hassle to support.

Remove old config file for SENTRY5

This is an older broadcom part that implements the mips32 ISA. 32-bit
FreeBSD/mips now requires mips32r2, so retire this config. Most of the
broadcom port is shared with newer ports, so what little code may be
unique to this part has not been GC'd at this time.

Remove Ingenic JZ4870 port

While this part is still relatively new, it's FreeBSD/mips only 32-bit
SMP port. Since newer atomics that are used in FreeBSD's MI part of
the kernel now require these atomics to be reliable 64-bit for
64-bits, and since there's no good way to implement them on a SMP
environment, retire this port. The boards aren't very relevant, is
over 4 years old and there will be no follow-on designs. As such, the
developer time to fix these issues costs more than the benefit we get
from having it in the tree. The boards were more expensive and less
powerful than the RPi series, and so had poor acceptance in the
marketplace.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

imp created this revision.Dec 13 2018, 7:58 PM

Herald added subscribers: emaste, andrew. · View Herald TranscriptDec 13 2018, 7:58 PM

Harbormaster completed remote builds in B21546: Diff 51971.Dec 13 2018, 7:58 PM

Looks good to me. This is a well reasoned list to remove in order to make sure we can support the remaining platforms.

This revision is now accepted and ready to land.Dec 14 2018, 6:42 AM

I prefer to deprecate chips / sub-arch, but not removal. Honestly approach with "unimplementable" atomic_64_swap looks too aggressive.
I and @yamori813_yahoo.co.jp have boards with mips4k SoCs and to be honest such chips do their job well.
Another point: I saw plenty of emails with information that 8Mb is very slow. If it looks small for certain group of people, it doesn't mean that it's small in wide audience. I see that firmware with kernel, modules, 20Mb of uncompressed UFS/CD9660 filesystem is powerful to handle plenty of tasks: routing, monitoring of sensors, graphical output to LCD, keyboard/IR control and so on.

Also I see that many people & companies (at least in Russia and Japan) use devices with mips4k/24k chips. Seriously, world still use 802.11a/g for wireless access and they are happy.
I would ask to deprecate chips if atomic_64_swap is "unimplementable" for them, rather than removal.

Hope for your understanding.

Thanks!

X1000 is a single-core IoT cpu released 3 years ago. X1000/E even newer. They are so nice, I bought 20 of them (only 5 USD each).
Since X1000 uses parts from jz4780, may be it is better to rename jz4780 to X1000 and remove SMP support.

In D18543#396125, @mizhka_gmail.com wrote:

I prefer to deprecate chips / sub-arch, but not removal. Honestly approach with "unimplementable" atomic_64_swap looks too aggressive.
I and @yamori813_yahoo.co.jp have boards with mips4k SoCs and to be honest such chips do their job well.
Another point: I saw plenty of emails with information that 8Mb is very slow. If it looks small for certain group of people, it doesn't mean that it's small in wide audience. I see that firmware with kernel, modules, 20Mb of uncompressed UFS/CD9660 filesystem is powerful to handle plenty of tasks: routing, monitoring of sensors, graphical output to LCD, keyboard/IR control and so on.

Also I see that many people & companies (at least in Russia and Japan) use devices with mips4k/24k chips. Seriously, world still use 802.11a/g for wireless access and they are happy.
I would ask to deprecate chips if atomic_64_swap is "unimplementable" for them, rather than removal.

mips24k is easy, and will remain. It's just the really old mips4k that are harder to implement this the way I wanted. I may have a way around that, but I'm not sure I have the time to test it properly.

The biggest issue I have with the old AR53xx ports is that we have no kernel configs for them, and we have no way to create them because parts are missing. If we can fix that, I'm OK using something a little less optimal that will work on the mips4k for the life of 13. But we really need to have that fixed for it to remain in the tree. I don't have time to chase this issue down.

In D18543#396137, @br wrote:

X1000 is a single-core IoT cpu released 3 years ago. X1000/E even newer. They are so nice, I bought 20 of them (only 5 USD each).
Since X1000 uses parts from jz4780, may be it is better to rename jz4780 to X1000 and remove SMP support.

If things work properly with that, I'm OK just removing the SMP kernel configs. I'd then make the 64-bit atomic not available in SMP land and let people that might want to use it cope as best they can (it's easier than actively removing the support, at least for now).
You'd need to confirm that things work after my changes, however.

Closed by commit rS342255: Remove support for the now very old SiByte MIPS platform. It's not (authored by imp). · Explain WhyDec 19 2018, 10:54 PM

This revision was automatically updated to reflect the committed changes.

Only the uncontested parts of this were committed. I'll open a new review for my solution to the Ingenic JZ ports. I'll monitor this review for further comments on the mips4k retirement that was objected to. The Ralink is easy to keep (assuming that I work out the atomic issue), but the AR53xx removal was motivated also by the fact that it's disconnected from the build at the moment and there's no config files and other infrastructure present to build it. That has to be fixed before we can retain that.