MIPS future...

[Mori Hiroki]

Hi


----- Original Message -----
>From: Warner Losh <imp at bsdimp.com>
>To: "freebsd-mips at freebsd.org" <freebsd-mips at freebsd.org> 
>Date: 2018/12/13, Thu 07:15
>Subject: Re: MIPS future...
> 
>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
>_______________________________________________
>freebsd-mips at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>
>
>

mips32 is called by 4K
mips32r2 is called by 24K

In current FreeBSD mips support at 4K is Rakink RT2880 and Atheros
AR531x. Ralink RT3050 later and Newer Atheros is 24K or 74K.


Also Broadcom BCM4712 and BCM5354 is 4K but it's still hangup. Last
Broadcom MIPS soc that is BCM4718 and BCM5357 is 74K.

I have question. Can do generate 24K code by gcc 4.2.1 and binutils?


Hiroki Mori