Date: Thu, 13 Dec 2018 11:12:45 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: Brooks Davis <brooks@freebsd.org>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: MIPS future... Message-ID: <CANCZdfpJ4QdiFURYX%2BEpJiY43MEUKFZypPscFGH40apPUQg55Q@mail.gmail.com> In-Reply-To: <201812131745.wBDHjWbT079862@pdx.rh.CN85.dnsmgr.net> References: <CANCZdfqTsf62dcecF3vhg1CBrx1BMuW9v_pASEWvVnmwNGKg0A@mail.gmail.com> <201812131745.wBDHjWbT079862@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 13, 2018 at 10:45 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <brooks@freebsd.org wrote: > > > > > On Wed, Dec 12, 2018 at 11:15:06AM -0700, Warner Losh 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. > > > > > > I think we have to do this no matter how expensive it is or kill 32-bit > > > mips. There is no way there are enough 32-bit mips users to justify > > > even the minor level of developer friction the unr64 caused. > > > > > > > Yes. That's the plan. The question is how. And part of that how is giving > > up on mips32 ISA (and requiring mips32r2 or newer). So I'll be doing > that. > > We have one SMP platform for 32bit mips that will have to die. It is > only 4 > > years old, but the design never caught on. > > Please verify that none of the MIPS based router (wifi-build, and > router project) stuff is killed, these are usefull, and I believe > active work is going on in both. > Give me some credit. I've already done that. None of the useful ones are affected. I've articulated the full list elsewhere. Basically the oldest Atheros stuff (The abg 180MHz AR53xx from 12 years ago) and the oldest Raylink stuff (first gen n 266MHz RT2880 from 9 or 10 years ago) are the only ones that this specific thing affects. The newer ones won't be affected. They are on the edge, but likely still useful to deploy. Last time I played with wifi-build I was able to boot a 8MB image > on a d-link router and had a working implementation, this was when > 12 was head. > But were you able to do more than just play with it? Things that small simply are too small. One CAN boot, but it's really hard to do things with it. So almost nobody does more than play with the extreme low end. Most of the routers I'm talking about didn't have more than 16MB of RAM typically with insufficient ROM to anything but store the naked kernel. There's much better choices available today cheap, and it's better we don't try to support them because the effort is kinda high and the reward from supporting niche hardware from a decade ago is almost zero. > Sean Bruno may know about here, he was the one that fixed some > of the issues I had run into since Adrian Chad is just too busy > with "life and kids :-)". > Yup. They are subscribed to the list. They can chime in if they care. Warner > > > > > 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. > > > > > > It looks like it's a sibyte platform if I read the config files > > > correctly. If so, I seriously doubt it works reliably under > meaningful, > > > multi-process load. We built at sibyte-like PIC for BERI and there > were > > > quite a few WTF moments as we adapted to code. > > > > > > > That confirms my expectations. It was shakey back in the day, and it can > > only be worse now... > > > > I don't have strong opinions on the other platforms. I know we haven't > > > used GXEMUL in at least 5 years on our projects. Qemu and the MALTA > > > config does everything we need. > > > > > > > Ok. I think gxemul users have moved to qemu and the burden of supporting > > two emulators is too great. > > > > Warner > > -- > Rod Grimes > rgrimes@freebsd.org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpJ4QdiFURYX%2BEpJiY43MEUKFZypPscFGH40apPUQg55Q>