Date: Wed, 12 Dec 2018 17:04:44 -0800 From: Juli Mallett <juli@northcloak.com> To: Warner Losh <imp@bsdimp.com> Cc: yamori813@yahoo.co.jp, freebsd-mips@freebsd.org Subject: Re: MIPS future... Message-ID: <CAGSiXYxtDH0MBHFwCGSXxjE-22JWdmFbkX8zK2j9FsTRqcVJZg@mail.gmail.com> In-Reply-To: <CANCZdfrfiR8=hd2nZsh1kuH6t_nbrdk=VHESZ4nzW-ZH2WfO-g@mail.gmail.com> References: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com> <CANCZdfq8PMDdnEnBeBsQ-evJph9Bf1P-gp3v3DYzeUWHV5FOAw@mail.gmail.com> <367298.45441.qm@web103901.mail.ssk.yahoo.co.jp> <CANCZdfrfiR8=hd2nZsh1kuH6t_nbrdk=VHESZ4nzW-ZH2WfO-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Dec 2018 at 16:12, Warner Losh <imp@bsdimp.com> wrote: > On Wed, Dec 12, 2018 at 3:53 PM Mori Hiroki <yamori813@yahoo.co.jp> wrote: > > > > > > > Hi > > > > > > ----- Original Message ----- > > >From: Warner Losh <imp@bsdimp.com> > > >To: "freebsd-mips@freebsd.org" <freebsd-mips@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@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@freebsd.org mailing list > > >https://lists.freebsd.org/mailman/listinfo/freebsd-mips > > >To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > > > > > > > > > > > > > mips32 is called by 4K > > mips32r2 is called by 24K > I would note that although MIPS (the company) pushed this naming for a period in the '00s, it can be confusing, because the R4000 (which was widely called R4K or sometimes even just 4K), which was the basis for a lot of MIPS CPUs, is actually MIPS-III (or mips3 in modern parlance, but I'm trapped in the '90s), and 64-bit rather than 32-bit. MIPS32, of course, is actually MIPS-III narrowed to 32-bit, plus a little extra. This leads some people to assume that MIPS32 came first, and then there were 64-bit CPUs, but this is not so. MIPS-III was 64-bit, R4000 was 64-bit, as were R4400, and all of the SGI CPUs and many third-party MIPS ISA CPUs of the late '90s. So I would slightly discourage use of the "4K" moniker and rather suggest using the ISA names, even though those confuse people, too, as consistently as possible, in a thread where bit-width, modernness, etc., are on the table. > > In current FreeBSD mips support at 4K is Rakink RT2880 and Atheros > > AR531x. Ralink RT3050 later and Newer Atheros is 24K or 74K. > > > > OK. That's good to know. The AR531x boards generally are under-provisioned > for memory, and somewhat slow. The RT2880 appears to be in the same class. > I'd be quite surprised if anybody could do anything non-trivial with those > boards. > > Also Broadcom BCM4712 and BCM5354 is 4K but it's still hangup. Last > > Broadcom MIPS soc that is BCM4718 and BCM5357 is 74K. > > > > So the older SENTRY5 chips, which weren't all that common, but which are > definitely mips4k chips. They are only a little better than the AR531x > chips. The newer BCM stuff still looks relevant. Thanks for the pointers. > > I have question. Can do generate 24K code by gcc 4.2.1 and binutils? > > > > I think that adding the following to the config file > makeoptions ARCH_FLAGS="-march=mips32r2" > comes close. You may need too add -EL if it's little endian. > > The only other config file tagged MIPS4k is GXEMUL, which may have run its > useful lifetime in FreeBSD as well. > > Warner > > P.S. I'll post a summary of the implications of mips32"r1" removal if > there's any opposition. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGSiXYxtDH0MBHFwCGSXxjE-22JWdmFbkX8zK2j9FsTRqcVJZg>