Skip site navigation (1)Skip section navigation (2)
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>