Date: Wed, 12 Dec 2018 15:15:19 -0700 From: Warner Losh <imp@bsdimp.com> To: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: MIPS future... Message-ID: <CANCZdfq8PMDdnEnBeBsQ-evJph9Bf1P-gp3v3DYzeUWHV5FOAw@mail.gmail.com> In-Reply-To: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com> References: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <imp@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq8PMDdnEnBeBsQ-evJph9Bf1P-gp3v3DYzeUWHV5FOAw>