MIPS future...

[Warner Losh]

On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <imp at bsdimp.com> wrote:

> OK. To be a good player in the FreeBSD ecosystem, we need to do  a few
> things.
>
> First, we need to implement atomic_swap_64. hps did this for mips64 and
> committed it. He sent me some further patches for it that I need to commit
> when I get a change, maybe at the airport tonight.
>
> But this brings up a couple of issues I'd like to bring up.
>
> First, to implement atomic_swap_64 on mips-32 is hard. In that it's not
> just the canonical ldd/sdd sequence because those aren't available there.
> We can do the standard trick of reading STATUS0, clearing IE, storing it,
> do the operation and then restoring STATUS0. This is efficient enough for
> the use in the kernel for the supported cores we have.
>
> With two exceptions. First is running 32-bit kernels on 64-bit hardware.
> We deprecated that with Octeon because of the weird hacks we needed to do
> too make it work. I'd like to universally deprecate this. There's little
> benefit and a real cost to doing this. I'd like to remove the SWARM_SMP,
> XLP, and GXEMUL32 (or at least remove the smp option).
>
> But there's JZ4780. It's a legit mips32 + SMP. It's on Image Creator's
> CI20. This was released in Nov 2014 with a refresh in March 2015. This is a
> dead-end product line (there's no new cores and none new that I can find).
> This was a RPi competitor, but it was slower, less capable and more
> expensive so it's kinda rare now. I'd say we need to de-support this
> device. I know of only one user, and he's not responded to my email. I
> think 12 will have to be the last release we have this in. Today, the only
> affect is for some drivers that can't run on this platform, but the writing
> is on the wall.
>
> That brings me to my next question: SWARM. Can we kill SWARM entirely?
> It's for the BCM1250 part, released in sometime before 2000. It was super
> popular because it was the reference for a ton of things that followed. I
> think it's run is over and we can remove it. I can find no users of it in
> the nyc dmesg database. Mine has been in a plastic bag since before my sone
> was born in 2006... So I'm thinking we can remove this platform. It was on
> the edge last time I did a GC in mips-land.
>
> And then there's the even larger question: how many people are still using
> mips32? It looks like a fair number, maybe, but I have no idea for sure, so
> if you do, please provide feedback on the platforms you are running FreeBSD
> 11 or newer on.
>

There's one last issue this brings up. When writing the above code, I
discovered I could use the non-racy DI instruction. However, that was
introduced with mips32r2. This was defined in 2002 and gear appeared in the
market 2004 or 2005. I believe that all supported SoCs have mips32r2. SWARM
doesn't, which is another reason to kill it: it's getting in the way and
providing no benefit. Would anybody object to the minimum ISA being raised
to mips32r2 for all 32-bit mips platforms?

Warner