onboard wireless on rpi4

[Klaus Cucinauomo]

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 <marklmi at yahoo.com>:
> 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 <marklmi at yahoo.com>:
> 
> 
> 
> On 2020-Sep-4, at 10:44, Klaus Cucinauomo <maciphone2 at googlemail.com> 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 <freebsd-arm at freebsd.org>:
>>>> 
>>> 
>>> 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)