onboard wireless on rpi4

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

onboard wireless on rpi4

tech-lists
Hi,

Is the onboard wifi on the rpi4 working in -current?

thanks,
--
J.

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

Re: onboard wireless on rpi4

Stefan Parvu
> Is the onboard wifi on the rpi4 working in -current?

Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.

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

Re: onboard wireless on rpi4

tech-lists
On Fri, Sep 04, 2020 at 05:07:50PM +0300, Stefan Parvu wrote:
>> Is the onboard wifi on the rpi4 working in -current?
>
>Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.

ok, thanks for clarifying. Is there anything more up-to-date on status of
FreeBSD on rpi4 (apart from https://wiki.freebsd.org/arm/Raspberry%20Pi which
was last updated on 2020-06-16).

I'm happy to test patches to help with work-in-progress. The rpi4 is the 8GB
version.
--
J.

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

Re: onboard wireless on rpi4

Kyle Evans-3
On Fri, Sep 4, 2020 at 9:23 AM tech-lists <[hidden email]> wrote:

>
> On Fri, Sep 04, 2020 at 05:07:50PM +0300, Stefan Parvu wrote:
> >> Is the onboard wifi on the rpi4 working in -current?
> >
> >Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.
>
> ok, thanks for clarifying. Is there anything more up-to-date on status of
> FreeBSD on rpi4 (apart from https://wiki.freebsd.org/arm/Raspberry%20Pi which
> was last updated on 2020-06-16).
>

Thanks to good work by Rob and others, we're likely at a point where
it makes sense to deprecate sysutils/u-boot-rpi4 and patch
sysutils/u-boot-rpi3 to work for both -- IIRC, that patch would just
modify the fragment to increase <mumble>DRAM_BANKS so that one can use
the full RAM on newer models.

sysutils/rpi-firmware could consolidate config_rpi4.txt and
config_rpi3.txt into one using conditional directives to use the
armstub on the RPi4.

Thanks,

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

Re: onboard wireless on rpi4

Ronald Klop
In reply to this post by Stefan Parvu
 
Van: Stefan Parvu <[hidden email]>
Datum: vrijdag, 4 september 2020 16:08
Aan: [hidden email]
Onderwerp: Re: onboard wireless on rpi4

>
> > Is the onboard wifi on the rpi4 working in -current?
>
> Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.
>
> Stefan
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
>
>
>


Is it really work in progress?
SDIO has landed which is a prerequisite for WiFi. Which is pretty nice. But after that I haven't seen much.
SDIO commit: https://svnweb.freebsd.org/base?view=revision&revision=348805

This page has a contact person: https://wiki.freebsd.org/SDIO. Last update of the page is a year ago.

As anybody I would love to test something.

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
the SDIO-implementation is „disfunctional" and misses some necessary requirements…
brcm wifi-drivers have to use external source-files and to translate nvram to detect
the different chipsets. It’s even possible that external sources differ from version to version of the same board.
All that is NOT implemented in the existing SDIO-„idea“ which only tries to „scan"
the hardware via the CAM-framework. A thing called SDIO-tool fails because of that(does nothing).
I cannot promise (because of many other things to do) but  perhaps would be willing to invest time to implement the drivers …
(! but only  if REALLY no one else is currently working on it. ! - to prevent double work and waste of time.. ) .
I guess(same as with the gnet-driver) the starting point is an existing driver-framework, in this case OpenBSD(
in approximately I know how it works because I worked a little with the devs in the past).

Regards

Klaus


>
> Is it really work in progress?
> SDIO has landed which is a prerequisite for WiFi. Which is pretty nice. But after that I haven't seen much.
> SDIO commit: https://svnweb.freebsd.org/base?view=revision&revision=348805
>
> This page has a contact person: https://wiki.freebsd.org/SDIO. Last update of the page is a year ago.
>
> As anybody I would love to test something.
>
> Regards,
> Ronald.
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"

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

Re: onboard wireless on rpi4

Stefan Parvu
In reply to this post by Ronald Klop
>
> Is it really work in progress?

AFAIK Bjoern promised to keep us informed about his progress. Yes, it is work in progress and based on Bjoern’s schedule and workload we should see some light on this part.

Stefan

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by Kyle Evans-3


On 2020-Sep-4, at 07:29, Kyle Evans <[hidden email]> wrote:

> On Fri, Sep 4, 2020 at 9:23 AM tech-lists <[hidden email]> wrote:
>>
>> On Fri, Sep 04, 2020 at 05:07:50PM +0300, Stefan Parvu wrote:
>>>> Is the onboard wifi on the rpi4 working in -current?
>>>
>>> Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.
>>
>> ok, thanks for clarifying. Is there anything more up-to-date on status of
>> FreeBSD on rpi4 (apart from https://wiki.freebsd.org/arm/Raspberry%20Pi which
>> was last updated on 2020-06-16).
>>
>
> Thanks to good work by Rob and others, we're likely at a point where
> it makes sense to deprecate sysutils/u-boot-rpi4 and patch
> sysutils/u-boot-rpi3 to work for both -- IIRC, that patch would just
> modify the fragment to increase <mumble>DRAM_BANKS so that one can use
> the full RAM on newer models.

Has the mishandling of the DMA been fixed? I'm still back
at head -r363590 and it was not fixed as of then. I've
had to use the 3072 MiB limit in the uefi/ACPI selections
in order to have a reliable environment.

> sysutils/rpi-firmware could consolidate config_rpi4.txt and
> config_rpi3.txt into one using conditional directives to use the
> armstub on the RPi4.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by Stefan Parvu
Yep, my question if really no one else is working on it, was directed to Björn ;-),
because I don’t want to work on a completely different implementation,
if Björn is perhaps a few steps further.

Klaus

> Am 04.09.2020 um 19:26 schrieb Stefan Parvu <[hidden email]>:
>
>>
>> Is it really work in progress?
>
> AFAIK Bjoern promised to keep us informed about his progress. Yes, it is work in progress and based on Bjoern’s schedule and workload we should see some light on this part.
>
> Stefan
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by freebsd-arm mailing list
Hi Mark,

as far as I remember(didn’t work the last weeks on RPI-stuff)
the dma-thing only failed on GENERIC-NODEBUG (unexpected controller detection loops) …
But it worked on GENERIC and afaik Greg_unrelenting`s dma-fix isn’t yet merged to 13-current
because of that unfixed issue…
(but you can apply his patch and test)..it should work under GENERIC without the 3GB-limit(4GB & 8GB-models)

Klaus

> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm <[hidden email]>:
>>
>
> Has the mishandling of the DMA been fixed? I'm still back
> at head -r363590 and it was not fixed as of then. I've
> had to use the 3072 MiB limit in the uefi/ACPI selections
> in order to have a reliable environment.
>

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by Kyle Evans-3
Some months ago I have often talked to ROBoCrow :-) e.g. about details of u-boot and the other files involved
in msdos-patition. We could manage bugfixes in "1-day-fashion“ thanks to his detail knowledge,
also discussed with genet-hero :-) Mike Karels..
Although I’m only the rpi4-Wiki-author and have absolutely nothing to do with fbsd-decisions :
I would strongly give a recommendation to you as a coreTeam-member and first RPI4-CPU-author:
You can invite ROBERT to accept FBSD-COMMIT-BITS, so that he can  overwrite RPI-related src-things(e.g.
your mentioned sysutils-thing etc.)…

Regards



> Am 04.09.2020 um 16:29 schrieb Kyle Evans <[hidden email]>:
>
> On Fri, Sep 4, 2020 at 9:23 AM tech-lists <[hidden email]> wrote:
>>
>> On Fri, Sep 04, 2020 at 05:07:50PM +0300, Stefan Parvu wrote:
>>>> Is the onboard wifi on the rpi4 working in -current?
>>>
>>> Nope. Does not even work on RBPI3/3B+. It is work in progress. We are waiting too.
>>
>> ok, thanks for clarifying. Is there anything more up-to-date on status of
>> FreeBSD on rpi4 (apart from https://wiki.freebsd.org/arm/Raspberry%20Pi which
>> was last updated on 2020-06-16).
>>
>
> Thanks to good work by Rob and others, we're likely at a point where
> it makes sense to deprecate sysutils/u-boot-rpi4 and patch
> sysutils/u-boot-rpi3 to work for both -- IIRC, that patch would just
> modify the fragment to increase <mumble>DRAM_BANKS so that one can use
> the full RAM on newer models.
>
> sysutils/rpi-firmware could consolidate config_rpi4.txt and
> config_rpi3.txt into one using conditional directives to use the
> armstub on the RPi4.
>
> Thanks,
>
> Kyle Evans
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by freebsd-arm mailing list


On 2020-Sep-4, at 10:44, Klaus Cucinauomo <[hidden email]> wrote:
>
> Hi Mark,

Hello.

> as far as I remember(didn’t work the last weeks on RPI-stuff)
> the dma-thing only failed on GENERIC-NODEBUG (unexpected controller detection loops) …

Unless trying to help track down a problem at the time, I use NODBG
kernels. So, for > 3072 MiB, I find that copying huge files and
diffing/cmp'ing the copies reports mismatches. (I tend to use
files larger than the RAM but that large has not been required.)
Note: I boot from and use USB3 SSD without a microsd card being
involved at any stage.

It is not obvious what the actual file contents are where the
differences show up.

I've tended to create and use tar's of build trees, created under
the 3072 MiB configuration to establish large files for such
tests. Tests under the 3072 MiB configuration have not failed
when I've tried such.

I have not tried this kind of test under a DBG kernel.

The last I heard about the PCIe DMA handling for > 3072 MiB was
on 2020-Jul-19 from Robert Crowston:

QUOTE
You are right that we are not handling the 3 GB DMA limit in the pcie driver. Unfortunately, it did not seem easy to thread the appropriate bus tag through without rewriting half the inherited driver stack, and in my testing the USB driver always allocated its DMA buffers in the lower 3 GB without being told. But obviously it is the wrong to rely on luck, so I’ll have a think about it.
END QUOTE

I've not noticed anything go by that suggested to me that this
has been addressed. (But I could have just missed it.)

> But it worked on GENERIC and afaik Greg_unrelenting`s dma-fix isn’t yet merged to 13-current
> because of that unfixed issue…
> (but you can apply his patch and test)..it should work under GENERIC without the 3GB-limit(4GB & 8GB-models)
>
> Klaus
>
>> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm <[hidden email]>:
>>>
>>
>> Has the mishandling of the DMA been fixed? I'm still back
>> at head -r363590 and it was not fixed as of then. I've
>> had to use the 3072 MiB limit in the uefi/ACPI selections
>> in order to have a reliable environment.
>>
>

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
Ah, thanks for making all those extended tests and reporting details !
I thought you’re talking about ACPI but the DMA-thing also affects DeviceTree,
at least in NODEBUG- kernel, as it seems after your report.

> Am 04.09.2020 um 21:19 schrieb Mark Millard <[hidden email]>:
> I have not tried this kind of test under a DBG kernel.

If you find the time, perhaps you could try it, thanks in advance !….

Well, USB/pcie related dma-things(rewriting half the inherited driver stack, mentioned by ROBoCrow)
are the specialty of fbsd-icon  HPS  :-) , so I also forward this issue/discussion to him for the first….
And 'myfreeweb' perhaps is also interested in ;-) ...

maybe after 3 months I will switch on the RPi4 again :-) Ha Ha

Regards

> Am 04.09.2020 um 21:19 schrieb Mark Millard <[hidden email]>:
>
>
>
> On 2020-Sep-4, at 10:44, Klaus Cucinauomo <[hidden email]> wrote:
>>
>> Hi Mark,
>
> Hello.
>
>> as far as I remember(didn’t work the last weeks on RPI-stuff)
>> the dma-thing only failed on GENERIC-NODEBUG (unexpected controller detection loops) …
>
> Unless trying to help track down a problem at the time, I use NODBG
> kernels. So, for > 3072 MiB, I find that copying huge files and
> diffing/cmp'ing the copies reports mismatches. (I tend to use
> files larger than the RAM but that large has not been required.)
> Note: I boot from and use USB3 SSD without a microsd card being
> involved at any stage.
>
> It is not obvious what the actual file contents are where the
> differences show up.
>
> I've tended to create and use tar's of build trees, created under
> the 3072 MiB configuration to establish large files for such
> tests. Tests under the 3072 MiB configuration have not failed
> when I've tried such.
>
> I have not tried this kind of test under a DBG kernel.
>
> The last I heard about the PCIe DMA handling for > 3072 MiB was
> on 2020-Jul-19 from Robert Crowston:
>
> QUOTE
> You are right that we are not handling the 3 GB DMA limit in the pcie driver. Unfortunately, it did not seem easy to thread the appropriate bus tag through without rewriting half the inherited driver stack, and in my testing the USB driver always allocated its DMA buffers in the lower 3 GB without being told. But obviously it is the wrong to rely on luck, so I’ll have a think about it.
> END QUOTE
>
> I've not noticed anything go by that suggested to me that this
> has been addressed. (But I could have just missed it.)
>
>> But it worked on GENERIC and afaik Greg_unrelenting`s dma-fix isn’t yet merged to 13-current
>> because of that unfixed issue…
>> (but you can apply his patch and test)..it should work under GENERIC without the 3GB-limit(4GB & 8GB-models)
>>
>> Klaus
>>
>>> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm <[hidden email]>:
>>>>
>>>
>>> Has the mishandling of the DMA been fixed? I'm still back
>>> at head -r363590 and it was not fixed as of then. I've
>>> had to use the 3072 MiB limit in the uefi/ACPI selections
>>> in order to have a reliable environment.
>>>
>>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)

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

Re: onboard wireless on rpi4

tech-lists
In reply to this post by freebsd-arm mailing list
On Fri, Sep 04, 2020 at 07:35:23PM +0200, Klaus Cucinauomo via freebsd-arm wrote:
>Yep, my question if really no one else is working on it, was directed to Björn ;-),
>because I don’t want to work on a completely different implementation,
>if Björn is perhaps a few steps further.

can't wait to test ;)

Is zfs available for rpi4?
--
J.

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

Re: onboard wireless on rpi4

freebsd-arm mailing list


> Am 04.09.2020 um 22:51 schrieb tech-lists <[hidden email]>:
>
> On Fri, Sep 04, 2020 at 07:35:23PM +0200, Klaus Cucinauomo via freebsd-arm wrote:
>> Yep, my question if really no one else is working on it, was directed to Björn ;-),
>> because I don’t want to work on a completely different implementation,
>> if Björn is perhaps a few steps further.
>
> can't wait to test ;)

Well, the decision is up to ‚bz‘ whether he wants to continue his hard work on it and whether he can give
free time  for it
OR
whether he wants to give  the implementation of brcm- wifi-drivers in
other hands(or whether he wants to add it to the „toDoList" so that others
should begin with that shi**y work, Ha Ha:-)… the last message was  :

> Anfang der weitergeleiteten Nachricht:
>
> Von: "Bjoern A. Zeeb" <[hidden email]>
> Betreff: Aw: Does freebsd support wifi for rpi4b?
> Datum: 29. Februar 2020 um 11:32:53 MEZ
> An: ykla <[hidden email]>
> Kopie: [hidden email]
>
>> …………….
>
> Not yet. Sorry.  It’s being worked on.
>
> See https://lists.freebsd.org/pipermail/freebsd-wireless/2020-February/008985.html <https://lists.freebsd.org/pipermail/freebsd-wireless/2020-February/008985.html>
>
> Keep an eye on the wireless list during the next month hopefully for more updates.
>
>
> /bz
> _______________________________________________
> [hidden email] <mailto:[hidden email]> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> To unsubscribe, send any mail to "[hidden email] <mailto:[hidden email]>"







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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by freebsd-arm mailing list
Regrettably the DMA problem is not fixed. After fixing the bus tag to correctly represent the DMA limit of the device, it reduced the problem incidence a lot but sometimes it still happens when the controller is under load. I think to do with the inbound/outbound memory view on the controller, i.e. maybe there is crosstalk between inbound and outbound DMA? I can submit the patch I have but it’s not a 100% fix.

Did someone tell me this is *not* a problem at all on NetBSD/OpenBSD?

— RHC.

On Fri, Sep 4, 2020 at 20:19, Mark Millard via freebsd-arm <[hidden email]> wrote:

> On 2020-Sep-4, at 10:44, Klaus Cucinauomo <[hidden email]> wrote:
>>
>> Hi Mark,
>
> Hello.
>
>> as far as I remember(didn’t work the last weeks on RPI-stuff)
>> the dma-thing only failed on GENERIC-NODEBUG (unexpected controller detection loops) …
>
> Unless trying to help track down a problem at the time, I use NODBG
> kernels. So, for > 3072 MiB, I find that copying huge files and
> diffing/cmp'ing the copies reports mismatches. (I tend to use
> files larger than the RAM but that large has not been required.)
> Note: I boot from and use USB3 SSD without a microsd card being
> involved at any stage.
>
> It is not obvious what the actual file contents are where the
> differences show up.
>
> I've tended to create and use tar's of build trees, created under
> the 3072 MiB configuration to establish large files for such
> tests. Tests under the 3072 MiB configuration have not failed
> when I've tried such.
>
> I have not tried this kind of test under a DBG kernel.
>
> The last I heard about the PCIe DMA handling for > 3072 MiB was
> on 2020-Jul-19 from Robert Crowston:
>
> QUOTE
> You are right that we are not handling the 3 GB DMA limit in the pcie driver. Unfortunately, it did not seem easy to thread the appropriate bus tag through without rewriting half the inherited driver stack, and in my testing the USB driver always allocated its DMA buffers in the lower 3 GB without being told. But obviously it is the wrong to rely on luck, so I’ll have a think about it.
> END QUOTE
>
> I've not noticed anything go by that suggested to me that this
> has been addressed. (But I could have just missed it.)
>
>> But it worked on GENERIC and afaik Greg_unrelenting`s dma-fix isn’t yet merged to 13-current
>> because of that unfixed issue…
>> (but you can apply his patch and test)..it should work under GENERIC without the 3GB-limit(4GB & 8GB-models)
>>
>> Klaus
>>
>>> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm <[hidden email]>:
>>>>
>>>
>>> Has the mishandling of the DMA been fixed? I'm still back
>>> at head -r363590 and it was not fixed as of then. I've
>>> had to use the 3072 MiB limit in the uefi/ACPI selections
>>> in order to have a reliable environment.
>>>
>>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: onboard wireless on rpi4

Bjoern A. Zeeb
In reply to this post by freebsd-arm mailing list
On 4 Sep 2020, at 17:35, Klaus Cucinauomo via freebsd-arm wrote:

> Yep, my question if really no one else is working on it, was directed
> to Björn ;-),
> because I don’t want to work on a completely different
> implementation,
> if Björn is perhaps a few steps further.

SDIO attach worked last year;  WiFi (cfg80211) wasn’t finished.  And I
am not tired of hearing people ask for it.  You have all the right to do
so.

I recently got a PCIe card (different bus attachment) but it should help
to move forward on the WiFi parts as well.  Yes, it is a free time
project at the moment but it also benefits from other ongoing WiFi work.


Two things which may help for the RPi/SDIO parts are:

- please try and use MMCCAM kernels and help, test, debug, report, ..
all the things you find so (other people) can jump in as well so we can
switch that on as default.  Without that, no SDIO.

- in case you are not only into RPi, the nanopi/rk33xx platforms with
onboard SDIO WiFi need tiny little glue bits to turn the bits on;  would
be great if someone could just do that.


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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by freebsd-arm mailing list
> Did someone tell me this is *not* a problem at all on NetBSD/OpenBSD?
while I have to update my knowledge of what happened the last weeks @ fbsd/netbsd/openbsd src(I didn’t work on it for some weeks)…
For OpenBSD that was probably me, for NetBSD must have been Mark...
both NetBSD and OpenBSD do NOT have an exclusive pcie-driver for the DeviceTree mode like
Fbsd has , thanks to you.
You remember the discussion with HPS and myfreeweb... :
https://github.com/pftf/RPi4/issues?page=2&q=is%3Aissue+is%3Aclosed
so for PCIe/fdt it’s an exclusive thing for you (and in terms of inheritance HPS, as far as I remember)
> I can submit the patch I have but it’s not a 100% fix.
Of course, please submit if you have something newer than already exists in Phabricator :
I’m sure that Mark(Millard)  is already sharpening his knife to give you test-feedback from his large-file tests;-)
And yes, your last dma-fix significantly reduced the problem of unexpected controller resets, but according to Mark not the
large file-copy-handling(I didn’t test that issues).

thank you,

kls

> Am 05.09.2020 um 10:59 schrieb Robert Crowston <[hidden email]>:
>
> Regrettably the DMA problem is not fixed. After fixing the bus tag to correctly represent the DMA limit of the device, it reduced the problem incidence a lot but sometimes it still happens when the controller is under load. I think to do with the inbound/outbound memory view on the controller, i.e. maybe there is crosstalk between inbound and outbound DMA? I can submit the patch I have but it’s not a 100% fix.
>
> Did someone tell me this is *not* a problem at all on NetBSD/OpenBSD?
>
>     — RHC.
>

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

Re: onboard wireless on rpi4

freebsd-arm mailing list
In reply to this post by Bjoern A. Zeeb
Hi Björn,
thanks that you’re still willing to invest work in aarch64 wifi.

> SDIO attach worked last year;

Ive tested that on RPI(4) extensively (of course with MMCCAM),
but as you already know(I assume), a brcmfmac-driver needs a loader mechanism for
the proprietary firmware -files and a mechanism to translate the nvram-file.
Nvram-translation can be done via an external program or can be built in into the driver.
So I really wonder how you got a brcmfmac- chip to work
without implementing those special drivers(and mechanisms) ????????

… I speak German like you  :-) so maybe I understood you wrong in the English language, sorry in advance ..

> - in case you are not only into RPi, the nanopi/rk33xx platforms with onboard SDIO WiFi need tiny little glue bits to turn the bits on;  would be great if someone could just do that.

The list of platforms which will load the firmware/nvram could be much longer than rpi/nanopi and as mentioned
in my earlier post it`s possible that 2 versions of the same board have to load different firmware-files
( that was the case for nanopi , as far as I remember,(I didn’t work much on aarch64 the last weeks)…

So long Blabla of details :-) … what I really wanted to know/ask you:

??? Are you working on the brcmfmac-driver AND the firmware-loading-mechanism???
??.. or are you doing things far more extended&advenced than my skills and knowledge of this topic:-) ???

Thanks and best Regards

Klaus


 

> Am 05.09.2020 um 14:15 schrieb Bjoern A. Zeeb <[hidden email]>:
>
> On 4 Sep 2020, at 17:35, Klaus Cucinauomo via freebsd-arm wrote:
>
>> Yep, my question if really no one else is working on it, was directed to Björn ;-),
>> because I don’t want to work on a completely different implementation,
>> if Björn is perhaps a few steps further.
>
> SDIO attach worked last year;  WiFi (cfg80211) wasn’t finished.  And I am not tired of hearing people ask for it.  You have all the right to do so.
>
> I recently got a PCIe card (different bus attachment) but it should help to move forward on the WiFi parts as well.  Yes, it is a free time project at the moment but it also benefits from other ongoing WiFi work.
>
>
> Two things which may help for the RPi/SDIO parts are:
>
> - please try and use MMCCAM kernels and help, test, debug, report, .. all the things you find so (other people) can jump in as well so we can switch that on as default.  Without that, no SDIO.
>
> - in case you are not only into RPi, the nanopi/rk33xx platforms with onboard SDIO WiFi need tiny little glue bits to turn the bits on;  would be great if someone could just do that.
>
>
> Bjoern

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

Re: onboard wireless on rpi4

tech-lists
In reply to this post by Bjoern A. Zeeb
On Sat, Sep 05, 2020 at 12:15:06PM +0000, Bjoern A. Zeeb wrote:
>
>Two things which may help for the RPi/SDIO parts are:
>
>- please try and use MMCCAM kernels and help, test, debug, report, ..
>all the things you find so (other people) can jump in as well so we can
>switch that on as default.  Without that, no SDIO.

Sure, it'll be the next thing i build on rpi4 after it's finished portmaster.
Will you need a dmesg posted somewhere?

Have to admit i've never built MMCCAM kernel before for rpi 1,2b+ or 3b+.
What's significant about it?

thanks,
--
J.

signature.asc (849 bytes) Download Attachment
123