Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context

[Mark Millard]

On 2020-Sep-20, at 06:15, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
> 
> 
>> Am 20.09.2020 um 03:32 schrieb Mark Millard <marklmi at yahoo.com>:
>> 
>> ...So: unrelated fixes. ...
> 
>> For the u-boot context, my guess is that the patch that
>> restricted the size of the DMA region to 1 GiByte or so
>> to allow things to progress there is effectively a work
>> around that avoids touching another bug(s) some place.
>> (NetBSD and Linux do not have such a small size limit.
>> OpenBSD choose its small limit for other reasons.)
> 
> 
> Ah, O.K., thanks, got it...
> 
> ..the bug is that dma of 1GB is always safe but there is no "OS-pre-implementation" 
> for 3GB buffer in 64-bit for RPI4… while , the pcie-device itself DOESN`t have the 
> 1GB - limit like other peripherals..
> ..
> NetBSD also did it that (OpenBSD-)way at first , not for other but the same reason, 
> I GUESS(!).. while , as you know,guessing(and dma) isn't really my area of expertise ;-) :

FYI: Here is what I found about OpenBSD's choice of its limit:

"OpenBSD can deal with the 3GB limit.  In fact it imposes a 1GB DMA limit because there are additional DMA restrictions for the SD controller." ( Mark Kettenis Aug 24, 2020; 4:29am Re: Discuss UEFI settingsin arm64.html/INSTALL.arm64 )

(Not that I have background knowledge that would confirm or deny the claim.)

> https://github.com/NetBSD/src/commit/5cb936da2a4720fa51984394998fa62c62aea7cd#diff-8e16a107fed72481ef0342727619cfa8  :
> 
> #define BCM2711_DMA_SIZE	0x3c000000 …,( which is 1GB)
> 
> jmcneill seems to have then added some voodoo in NetBSD :
> https://github.com/NetBSD/src/commit/9bf4ec11d132c8b296a3926483aa0b8d43fa43ad
> 
> the Tux has fixed it there :
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/arm64/iort.c?h=v5.8&id=bcf876870b95592b52519ed4aafcf9d95999bc9c#n1125
> ..they have things like dma_zone or so...
> 
> So hardcoding the 1GB constraint into https://reviews.freebsd.org/D25219 
> or
> give it a fine grain dma range to 3GB should fix it...

An interesting item from the Fedora 33 branch (late Oct. release planned):
Note below the 3 GiByte wide DMA32 range is listed as shifted by 1 GiByte.
This is for a 5.8.7-300.fc33.aarch64 kernel. (I used the uefi/ACPI v1.20 to
boot Fedora server, not limiting to 3072 MiB.)

   [    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
   [    0.000000] NUMA: NODE_DATA [mem 0x1fefec8c0-0x1ff002fff]
   [    0.000000] Zone ranges:
   [    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
   [    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
   [    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
   [    0.000000]   Device   empty
   [    0.000000] Movable zone start for each node
   [    0.000000] Early memory node ranges
   [    0.000000]   node   0: [mem 0x0000000000000000-0x00000000001fffff]
   [    0.000000]   node   0: [mem 0x0000000000200000-0x00000000337d7fff]
   [    0.000000]   node   0: [mem 0x00000000337d8000-0x000000003387ffff]
   [    0.000000]   node   0: [mem 0x0000000033880000-0x000000003390ffff]
   [    0.000000]   node   0: [mem 0x0000000033910000-0x000000003398ffff]
   [    0.000000]   node   0: [mem 0x0000000033990000-0x00000000339affff]
   [    0.000000]   node   0: [mem 0x00000000339b0000-0x0000000033a2ffff]
   [    0.000000]   node   0: [mem 0x0000000033a30000-0x0000000036efffff]
   [    0.000000]   node   0: [mem 0x0000000036f00000-0x00000000372dffff]
   [    0.000000]   node   0: [mem 0x00000000372e0000-0x000000003b2fffff]
   [    0.000000]   node   0: [mem 0x0000000040000000-0x00000000fbffffff]
   [    0.000000]   node   0: [mem 0x0000000100000000-0x00000001ffffffff]
   [    0.000000] Zeroed struct page in unavailable ranges: 552 pages
   [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]

I don't know enough to know if this indicates a problem
in/for Fedora for an RPi4B or not.

I just did a "yum update" and the 5.8.10-300.fc33.aarch64 kernel
that resulted boots reporting the same for DMA32:

[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x1fefed8c0-0x1ff003fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x00000000001fffff]
[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000337e7fff]
[    0.000000]   node   0: [mem 0x00000000337e8000-0x000000003388ffff]
[    0.000000]   node   0: [mem 0x0000000033890000-0x000000003390ffff]
[    0.000000]   node   0: [mem 0x0000000033910000-0x000000003398ffff]
[    0.000000]   node   0: [mem 0x0000000033990000-0x00000000339affff]
[    0.000000]   node   0: [mem 0x00000000339b0000-0x0000000033a2ffff]
[    0.000000]   node   0: [mem 0x0000000033a30000-0x0000000036efffff]
[    0.000000]   node   0: [mem 0x0000000036f00000-0x00000000372dffff]
[    0.000000]   node   0: [mem 0x00000000372e0000-0x000000003b2fffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000fbffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x00000001ffffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 536 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]

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