Date: Fri, 2 Oct 2020 19:35:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4B 3 GiByte pcie limitation: The following change survived my huge-file duplicate-and-diff tests so far Message-ID: <447B28E3-3964-4498-A91D-528EA5923793@yahoo.com> In-Reply-To: <7506FD70-D814-4F64-BFAF-CCCE9A0D71A3@yahoo.com> References: <7506FD70-D814-4F64-BFAF-CCCE9A0D71A3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Operator error note and another note.] On 2020-Oct-2, at 13:56, Mark Millard <marklmi at yahoo.com> wrote: > It appears to me that 3 GiByte works for lowaddr and > maxsize but that the maxsegsz needs to be limited to > 1 GiByte [or so, maybe (1 Gi - 1) Bytes]. >=20 > I did the following based on all those notes that I > sent out, that included the ?_TXFR_LEN being limited > 30 bits for (normal) DMA engines (0-6) and the DMA4 > engines (11-14) [but not DMA LITE (7-10)]: Ignore: I had the wrong kernel build installed. In fact the below fails when the intended kernel is tested. > # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c = /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision = 365932) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > @@ -105,7 +105,8 @@ > * > * Whatever the true maximum address, 960 MiB works. > */ > -#define DMA_HIGH_LIMIT 0x3c000000 > +#define DMA_SEG_HIGH_LIMIT 0x3c000000 > +#define DMA_TOTAL_HIGH_LIMIT 0xc0000000 > #define MAX_MEMORY_LOG2 0x21 > #define REG_VALUE_DMA_WINDOW_LOW (MAX_MEMORY_LOG2 - 0xf) > #define REG_VALUE_DMA_WINDOW_HIGH 0x0 > @@ -642,12 +643,12 @@ > */ > error =3D bus_dma_tag_create(bus_get_dma_tag(dev), /* parent */ > 1, 0, /* alignment, bounds */ > - DMA_HIGH_LIMIT, /* lowaddr */ > + DMA_TOTAL_HIGH_LIMIT, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > - DMA_HIGH_LIMIT, /* maxsize */ > + DMA_TOTAL_HIGH_LIMIT, /* maxsize */ > BUS_SPACE_UNRESTRICTED, /* nsegments */ > - DMA_HIGH_LIMIT, /* maxsegsize */ > + DMA_SEG_HIGH_LIMIT, /* maxsegsize */ > 0, /* flags */ > NULL, NULL, /* lockfunc, lockarg */ > &sc->dmat); >=20 >=20 > Then, with such a kernel installed, I used: >=20 > -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 = clang-armv7-on-aarch64.tar >=20 > (so much larger than the 8 GiByte RAM) and did the following with > the file: >=20 > # cp -aRx clang-armv7-on-aarch64.tar clang-armv7-on-aarch64.alt_tar > # diff clang-armv7-on-aarch64.tar clang-armv7-on-aarch64.alt_tar > # >=20 > Such tests have been passing. >=20 > I do not know what your test procedures were. But if the above > is suggestive, you might want to try testing something like the > above via your test procedures. Going in a different direction for potential maxsegsz figures (and the like): xhci instead of bcm2711 material . . . extensible-host-controler-interface-usb-xhci.pdf reports that normal TRB Transfer Length fields have bits 16:0 and "Valid values are 0 to 64K". (Transfer Event TRB Transfer Lengths have 23:0 but above 0x10000 as a value is only for Event Data flag being 1 or for condition code is stopped - short packet.) I've not experimented with this. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?447B28E3-3964-4498-A91D-528EA5923793>