MIPS future...

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

MIPS future...

Warner Losh
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.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Kyle Evans-3
On Wed, Dec 12, 2018 at 12:15 PM Warner Losh <[hidden email]> wrote:
>
> [... snip ...]
>
> 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.
>

Hi,

CARAMBOLA2 here, and I think I've seen some reports of mileage on TL-*
and/or TP-* boards from freebsd-wifi-build users.

Thanks,

Kyle Evans
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
In reply to this post by Warner Losh
On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Mori Hiroki


Hi


----- Original Message -----

>From: Warner Losh <[hidden email]>
>To: "[hidden email]" <[hidden email]>
>Date: 2018/12/13, Thu 07:15
>Subject: Re: MIPS future...
>
>On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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
>_______________________________________________
>[hidden email] mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>To unsubscribe, send any mail to "[hidden email]"
>
>
>

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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
On Wed, Dec 12, 2018 at 3:53 PM Mori Hiroki <[hidden email]> wrote:

>
>
> Hi
>
>
> ----- Original Message -----
> >From: Warner Losh <[hidden email]>
> >To: "[hidden email]" <[hidden email]>
> >Date: 2018/12/13, Thu 07:15
> >Subject: Re: MIPS future...
> >
> >On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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
> >_______________________________________________
> >[hidden email] mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> >To unsubscribe, send any mail to "[hidden email]"
> >
> >
> >
>
> 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.
>

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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Eugene Grosbein-10
In reply to this post by Warner Losh
13.12.2018 1:15, Warner Losh wrote:

> 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.

I have TP-Link TL-WDR4300 https://www.tp-link.com/en/products/details/TL-WDR4300.html
that is MIPS32 74Kc AR9344 SOC with 8MB on-board flash and 128M RAM
that successfully boots to multiuser mode using very old FreeBSD 11-CURRENT.

I stopped trying it because its USB support was pretty unstable leading to random panics or just hangs and
8MB are not enough for my purposes without extra USB storage for packages and
I could not even fit FreeBSD 12 base system to its internal flash due to siginficantly increased code bloat
and ENOTIME to deal with troubles.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Juli Mallett-4
In reply to this post by Warner Losh
On Wed, 12 Dec 2018 at 16:12, Warner Losh <[hidden email]> wrote:

> On Wed, Dec 12, 2018 at 3:53 PM Mori Hiroki <[hidden email]> wrote:
>
> >
> >
> > Hi
> >
> >
> > ----- Original Message -----
> > >From: Warner Losh <[hidden email]>
> > >To: "[hidden email]" <[hidden email]>
> > >Date: 2018/12/13, Thu 07:15
> > >Subject: Re: MIPS future...
> > >
> > >On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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
> > >_______________________________________________
> > >[hidden email] mailing list
> > >https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> > >To unsubscribe, send any mail to "[hidden email]"
> > >
> > >
> > >
> >
> > 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.
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
On Wed, Dec 12, 2018 at 6:05 PM Juli Mallett <[hidden email]> wrote:

> On Wed, 12 Dec 2018 at 16:12, Warner Losh <[hidden email]> wrote:
>
>> On Wed, Dec 12, 2018 at 3:53 PM Mori Hiroki <[hidden email]>
>> wrote:
>>
>> >
>> >
>> > Hi
>> >
>> >
>> > ----- Original Message -----
>> > >From: Warner Losh <[hidden email]>
>> > >To: "[hidden email]" <[hidden email]>
>> > >Date: 2018/12/13, Thu 07:15
>> > >Subject: Re: MIPS future...
>> > >
>> > >On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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
>> > >_______________________________________________
>> > >[hidden email] mailing list
>> > >https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> > >To unsubscribe, send any mail to "[hidden email]
>> "
>> > >
>> > >
>> > >
>> >
>> > 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.
>

True enough, later in my reply. I should have said 'mips4kc' since that's
the core name that implements the 'mips32' ISA. I agree this is just about
as confusing a set of conflicting naming conventions that could exist.

Warner


> > 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.
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Brooks Davis-2
In reply to this post by Warner Losh
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.

> 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.

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.

-- Brooks

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <[hidden email] 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.

> 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

>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Rodney W. Grimes-4
> On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <[hidden email] 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.

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.

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 :-)".

>
> > 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                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
On Thu, Dec 13, 2018 at 10:45 AM Rodney W. Grimes <
[hidden email]> wrote:

> > On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <[hidden email] 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
> [hidden email]
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Warner Losh
In reply to this post by Warner Losh
On Wed, Dec 12, 2018 at 11:15 AM Warner Losh <[hidden email]> 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.
>

I've done a preliminary pass at removing this old support. I've included
the mips32 ISA (generally the MIPS4Kc core) removal as well. It's a big
review, but I've chopped it into individual commits in case one of them
winds up being backed out: https://reviews.freebsd.org/D18543

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Bernd Walter-4
In reply to this post by Eugene Grosbein-10
On Thu, Dec 13, 2018 at 08:04:17AM +0700, Eugene Grosbein wrote:

> 13.12.2018 1:15, Warner Losh wrote:
>
> > 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.
>
> I have TP-Link TL-WDR4300 https://www.tp-link.com/en/products/details/TL-WDR4300.html
> that is MIPS32 74Kc AR9344 SOC with 8MB on-board flash and 128M RAM
> that successfully boots to multiuser mode using very old FreeBSD 11-CURRENT.

I'm using one of them as an AP in one location with the mini-build.
My other locatin was using an OpenWRT AP, but just yesterday I finally setup
FreeBSD-12 stable to replace the OpenWRT.
It was very tricky to find out what modules had to be loaded to get WiFi
working.
And on how to start them without loader perloading modules.
I finally came up with the following rc.local:
/sbin/kldload wlan_xauth
/sbin/kldload ath_hal_ar9300.ko
/sbin/kldload if_ath_ahb.ko
/sbin/kldload if_ath_pci.ko
sleep 1
/sbin/ifconfig bridge0 unplumb
sleep 1
/sbin/ifconfig bridge0 plumb


>
> I stopped trying it because its USB support was pretty unstable leading to random panics or just hangs and
> 8MB are not enough for my purposes without extra USB storage for packages and
> I could not even fit FreeBSD 12 base system to its internal flash due to siginficantly increased code bloat
> and ENOTIME to deal with troubles.

Same, the instable USB support was what killed most of my ambitions with that.
This is a showstopper for other boards as well.
Don't know if this specific to atheros, but I've tested several atheros
based boards and USB just wasn't working well enough for a rootfs.
Maybe that has changed since my last test...
Since it is for my own need with existing infrastructure, the TL-WDR4300
is using nfsroot.
However, there are still some issues.
It is bridging to the WiFi, but I like to have isolation.
Since it is nfsroot, I can't use normal VLANs to my gateway.
I should be able to use VXLAN to my normal gateway however.
Routing is not an option as I can't install packages/ports for dhcp:
root@apx1:~ # pkg
ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg"
root@apx1:~ # which cc
cc: Command not found.

The rootfs is via ../root/mips_ap/ build by the freebsd-wifi-build.
Beside the missing cc it looks pretty much complete.
Maybe a normal crossbuild would get me a compiler?

That said, if I can't have a working compiler, I would try vxlan, but still
a working compiler would be nice to have.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Adrian Chadd-4
On Wed, 24 Apr 2019 at 03:11, Bernd Walter <[hidden email]> wrote:

>
> On Thu, Dec 13, 2018 at 08:04:17AM +0700, Eugene Grosbein wrote:
> > 13.12.2018 1:15, Warner Losh wrote:
> >
> > > 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.
> >
> > I have TP-Link TL-WDR4300 https://www.tp-link.com/en/products/details/TL-WDR4300.html
> > that is MIPS32 74Kc AR9344 SOC with 8MB on-board flash and 128M RAM
> > that successfully boots to multiuser mode using very old FreeBSD 11-CURRENT.
>
> I'm using one of them as an AP in one location with the mini-build.
> My other locatin was using an OpenWRT AP, but just yesterday I finally setup
> FreeBSD-12 stable to replace the OpenWRT.
> It was very tricky to find out what modules had to be loaded to get WiFi
> working.

I'm actively working on trying to tidy this up on -HEAD (on the MIPS
boards) because, well, I'm back to trying to make it all work well.
There's support for the last two chips (dragonfly, honeybee) that I
need to finish and bring over too.

> And on how to start them without loader perloading modules.
> I finally came up with the following rc.local:
> /sbin/kldload wlan_xauth
> /sbin/kldload ath_hal_ar9300.ko
> /sbin/kldload if_ath_ahb.ko
> /sbin/kldload if_ath_pci.ko
> sleep 1
> /sbin/ifconfig bridge0 unplumb
> sleep 1
> /sbin/ifconfig bridge0 plumb

Yeah. Part of the unfun part of the FreeBSD wifi experience is that
devices take non-zero amounts of time to do stuff in deferred threads,
so there's fun race conditions when trying to script bringing things
up. It used to be easier - everything would block in the ioctl path
for loading, creating/destroying interfaces, etc - but the newer
firmware NICs have stuff deferred into async calls and they don't all
block the ioctl path. So, sometimes you need sleeps until the
interface has been fully loaded/plumbed.

It's one of the many annoying things in my ath10k port that I'm trying
to chip away at.

> > I stopped trying it because its USB support was pretty unstable leading to random panics or just hangs and
> > 8MB are not enough for my purposes without extra USB storage for packages and
> > I could not even fit FreeBSD 12 base system to its internal flash due to siginficantly increased code bloat
> > and ENOTIME to deal with troubles.

I'm working on this right now too. Annoying the biggest thing I need
help with is that we can't build without SSL because of how
libunbound/libldns is built. It has a checked in config.h from
configure which hard-enables SSL. Hopefully I can build
hostapd/wpa_supplciant with the built-in crypto routines to get some
savings.

If I can get rid of needing libcrypto and libssl in the wifi AP builds
then we save a few megabytes of space; enough to fit in 8MB again. i'm
working on a cpio-like tool to replace cpio/libarchive because
libarchive is also quite large (almost a megabyte + libcrypto
depedency) which we don't need right now.

>
> Same, the instable USB support was what killed most of my ambitions with that.
> This is a showstopper for other boards as well.
> Don't know if this specific to atheros, but I've tested several atheros
> based boards and USB just wasn't working well enough for a rootfs.
> Maybe that has changed since my last test...

Is this USB on the atheros chips? what's wrong with it? It /used/ to
be enough to run a rootfs from but I haven't done that in a few years
and there's been some changes to the USB stack since then.

> Since it is for my own need with existing infrastructure, the TL-WDR4300
> is using nfsroot.
> However, there are still some issues.
> It is bridging to the WiFi, but I like to have isolation.
> Since it is nfsroot, I can't use normal VLANs to my gateway.
> I should be able to use VXLAN to my normal gateway however.
> Routing is not an option as I can't install packages/ports for dhcp:
> root@apx1:~ # pkg
> ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg"
> root@apx1:~ # which cc
> cc: Command not found.

Is this from my freebsd-wifi-build scripts? Yeah, some stuff needs
updating again. I am working on that too. ;-)

> The rootfs is via ../root/mips_ap/ build by the freebsd-wifi-build.
> Beside the missing cc it looks pretty much complete.
> Maybe a normal crossbuild would get me a compiler?

It won't get you one in my normal image because it's too big.

>
> That said, if I can't have a working compiler, I would try vxlan, but still
> a working compiler would be nice to have.

The FreeBSD targets for the AP have a lot of stuff removed in the
build. I used to use an option in freebsd-wifi-build to build non-AP
images (ie, full cross-built images) which unfortunately won't include
a compiler until that is also added in as a cross-build target.

Poke me repeatedly on #freebsd-wifi ; I'll keep plodding through this
list now that I'm poking at it again.



-adrian
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: MIPS future...

Bernd Walter-4
On Sun, May 19, 2019 at 09:01:52AM -0700, Adrian Chadd wrote:

> On Wed, 24 Apr 2019 at 03:11, Bernd Walter <[hidden email]> wrote:
> >
> > On Thu, Dec 13, 2018 at 08:04:17AM +0700, Eugene Grosbein wrote:
> > > 13.12.2018 1:15, Warner Losh wrote:
> > >
> > I'm using one of them as an AP in one location with the mini-build.
> > My other locatin was using an OpenWRT AP, but just yesterday I finally setup
> > FreeBSD-12 stable to replace the OpenWRT.
> > It was very tricky to find out what modules had to be loaded to get WiFi
> > working.
>
> I'm actively working on trying to tidy this up on -HEAD (on the MIPS
> boards) because, well, I'm back to trying to make it all work well.
> There's support for the last two chips (dragonfly, honeybee) that I
> need to finish and bring over too.
>
> > And on how to start them without loader perloading modules.
> > I finally came up with the following rc.local:
> > /sbin/kldload wlan_xauth
> > /sbin/kldload ath_hal_ar9300.ko
> > /sbin/kldload if_ath_ahb.ko
> > /sbin/kldload if_ath_pci.ko
> > sleep 1
> > /sbin/ifconfig bridge0 unplumb
> > sleep 1
> > /sbin/ifconfig bridge0 plumb
>
> Yeah. Part of the unfun part of the FreeBSD wifi experience is that
> devices take non-zero amounts of time to do stuff in deferred threads,
> so there's fun race conditions when trying to script bringing things
> up. It used to be easier - everything would block in the ioctl path
> for loading, creating/destroying interfaces, etc - but the newer
> firmware NICs have stuff deferred into async calls and they don't all
> block the ioctl path. So, sometimes you need sleeps until the
> interface has been fully loaded/plumbed.

I rewmoved the sleep and ifconfig bridge0 in favour of:
cloned_interfaces="bridge0"
#ifconfig_bridge0="addm wlan0 addm wlan1 addm arge0 up"
ifconfig_bridge0="up"
autobridge_interfaces="bridge0"
autobridge_bridge0="wlan* arge0"

The problem was that, because I load the drivers via rc.local, the
wlan interfaces came up after bridge0

> It's one of the many annoying things in my ath10k port that I'm trying
> to chip away at.
>
> > > I stopped trying it because its USB support was pretty unstable leading to random panics or just hangs and
> > > 8MB are not enough for my purposes without extra USB storage for packages and
> > > I could not even fit FreeBSD 12 base system to its internal flash due to siginficantly increased code bloat
> > > and ENOTIME to deal with troubles.
>
> I'm working on this right now too. Annoying the biggest thing I need
> help with is that we can't build without SSL because of how
> libunbound/libldns is built. It has a checked in config.h from
> configure which hard-enables SSL. Hopefully I can build
> hostapd/wpa_supplciant with the built-in crypto routines to get some
> savings.
>
> If I can get rid of needing libcrypto and libssl in the wifi AP builds
> then we save a few megabytes of space; enough to fit in 8MB again. i'm
> working on a cpio-like tool to replace cpio/libarchive because
> libarchive is also quite large (almost a megabyte + libcrypto
> depedency) which we don't need right now.
>
> >
> > Same, the instable USB support was what killed most of my ambitions with that.
> > This is a showstopper for other boards as well.
> > Don't know if this specific to atheros, but I've tested several atheros
> > based boards and USB just wasn't working well enough for a rootfs.
> > Maybe that has changed since my last test...
>
> Is this USB on the atheros chips? what's wrong with it? It /used/ to
> be enough to run a rootfs from but I haven't done that in a few years
> and there's been some changes to the USB stack since then.

I havn't tested it with 12-STABLE, when I tried an USB rootfs few years
ago, the USB drive wasn't stable and started producing IO errors after
a few hours of uptime.
This was reproduceabl witgh various kinds of USB sticks and HDD on the
TP-Link WDR-4300 with its ATH9344 as well as on various AR9331 based
boards.

> > Since it is for my own need with existing infrastructure, the TL-WDR4300
> > is using nfsroot.
> > However, there are still some issues.
> > It is bridging to the WiFi, but I like to have isolation.
> > Since it is nfsroot, I can't use normal VLANs to my gateway.
> > I should be able to use VXLAN to my normal gateway however.
> > Routing is not an option as I can't install packages/ports for dhcp:
> > root@apx1:~ # pkg
> > ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg"
> > root@apx1:~ # which cc
> > cc: Command not found.
>
> Is this from my freebsd-wifi-build scripts? Yeah, some stuff needs
> updating again. I am working on that too. ;-)

That is a general problem with ancient packages.
The pkg binary package is outdated by at least half a year and build
against an on older OpenSSL version.
[56]apx1> ls -al /usr/lib/*ssl*
-r--r--r--  1 root  wheel  3708526 Apr 23 19:22 /usr/lib/libssl.a
lrwxr-xr-x  1 root  wheel       13 Apr 23 19:22 /usr/lib/libssl.so -> libssl.so.111
-r--r--r--  1 root  wheel   590876 Apr 23 19:22 /usr/lib/libssl.so.111
-r--r--r--  1 root  wheel  3771294 Apr 23 19:22 /usr/lib/libssl_p.a

> > The rootfs is via ../root/mips_ap/ build by the freebsd-wifi-build.
> > Beside the missing cc it looks pretty much complete.
> > Maybe a normal crossbuild would get me a compiler?
>
> It won't get you one in my normal image because it's too big.
>
> >
> > That said, if I can't have a working compiler, I would try vxlan, but still
> > a working compiler would be nice to have.
>
> The FreeBSD targets for the AP have a lot of stuff removed in the
> build. I used to use an option in freebsd-wifi-build to build non-AP
> images (ie, full cross-built images) which unfortunately won't include
> a compiler until that is also added in as a cross-build target.

Ok, so that should work if I do a standard crossbuild.

> Poke me repeatedly on #freebsd-wifi ; I'll keep plodding through this
> list now that I'm poking at it again.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "[hidden email]"