From owner-freebsd-arm@freebsd.org Mon Oct 12 17:37:56 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 911D043CD19 for ; Mon, 12 Oct 2020 17:37:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C95VV1YBzz4T1t for ; Mon, 12 Oct 2020 17:37:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: tx14CK4VM1kF863vOy4euoKbNLyQsY4cWMNCr1ULxy5LS4oe6B7Afpr4q315lG8 EOQcSMNM.oBYjICcFs3sAmRhvF98ck1M4hat1Awf592ZS_G5QEynY9ZrbSJXyt__Uo1Xk2Hz2TOQ rt1slnXKO9yV1BBXP5zsIpmISEFxKQbLyD2ZKkjdCFsYWGTlOUIU7yFcfUgCFYKI50dmycrSgCJ7 XmHaWdKG2RENJnCSoTYBbPXq2hkVcEspkrsrh89wU9CI_4HmCb_yPn8zT0wiK0p8dR8fiYrly76L _fy_80opUuCm.jx._4TCWqdFp3KpddsYsa0wbGq1.Sz9vS.7_ZEHU__ZziPUGMIBchE1mqhgAJsX CO.ucPYFeih_qYEUJDmeDgqwLV7U_p8QfUnxZdrewaG91lzyk__1MkTfURJ9zAE8E6ey2MQaTtmt g7riUT20vQludq6c_VvNz_mpb5Z_nlvDrIrtGZR3iPqQLnmgtm8WRQJTdJB8SSKqi_NVeXz7BcFN ZprTaOOrhybMKxcs2qLQq6.M2ISEmZypUGz.J.lY4GFTvTcD_.EzqoZtoBCGOK_tPvVm8YXLdsxZ XwdkM6de_LDRDSNgtzdGSHQ6Wl_Io2h.9Rxkp8Hd1y2RqRbIQUIURmRNQEVPE0gpOC1SkkQUAaaz ka5faL0toDkZWKkA3kV.iIYhyNdgqPruwCMKWnLpLWRsdL4jrcPojqqiDL6NlCy7FQqQSq8_y.kM cUml5AdH5MbdQ6uAYp5P1TcHXoPDDMEiIvi4w9_.YdZytfUe2xTtyHJ8_Y4AjTb_AmhAjAVIE6we JnC7fcjVrbqFv6s3DG9kxokQoMjppJnobWxCBgpUTUXUEEKwiOHzj9qqG72jSncfut0I.o8OhwWH qp.silwmhE0Onhc6gXT644aphC_j.N4hACSc6zBhDKXbQ9_ZU.xnPwupgMSGSGj763dzlSzJcs.X tVRFdlpA8Lgl8CHGTVsOw6eawOR0WAMOIo6_DuhTpXVoaEKIFqVDub2anuPtysUuodKBe0JDZ6UX SAKSlYUe2ffj1FFFdpeJYJWthRDcLSt3_uDwC.Zzz1EwnwySnwOK2Y7DItKc8Rvktc3T5KRlarFC Rqm06J8IFTOVuoWmg._khbL9ZDHEfj6Ann4yWo89.CHaWlNeULp8XfcMc7iWnT6sEn1w1HGrIRqs bKwibWNELy7icGP5R9m16fJ8V1QQhP2cR86Kx9x6LaDYt4Ygk1pX.vPywTRCtqb57Ibyz__h0QsV fb_lt9_P_aDbXNbl_8qJBXWEPXqIOD4_NWZXekUxNYnM1E43Gook1q_W9ggXpQVCUms9B2kRcBXz ww4ZduBO62hpL9wjvc.VSPDfqrpGEKVOn9YGfRI73T0fqSaD.p4ti8ovwVBKScixej0moLNrkEcI JWeBFxN9GECPnsfM6OhKyRdNO2p.Dtp9dLrTVMEk_OCGT9mVQ5qLRnE6DJRaDqZ3gr.FseX9hQD9 oa9wqNlvnTWcg8h.61M0JINHahX94NQMdSqjjQTRzRX.OWACEy.6c3vRjrrKw1IhqH45RzaPbLs_ xigA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Oct 2020 17:37:51 +0000 Received: by smtp403.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1262546cc1874ae40411569f8226df68; Mon, 12 Oct 2020 17:37:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]? From: Mark Millard In-Reply-To: Date: Mon, 12 Oct 2020 10:37:44 -0700 Cc: Robert Crowston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> <3E9D015B-5702-4A52-9366-49E20BDDA5F4@googlemail.com> <79AA6AB2-9FE6-4A80-9E72-F6D7B7E6803F@googlemail.com> <3577889D-3102-4B50-955B-798717F93F92@googlemail.com> <0m0EOJpW7j-ziTjqjNz5Ldul7r8DT9bCjmgmsm5-kr9dX5pt2PEoQrZcFJ9nxtB8YXpqdrBk2ecMIjfijv3DEV26M9fzu3nwwQ90msFZBmw=@protonmail.com> <22B0D423-CEF4-4B74-846D-6F668A0F0B9F@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C95VV1YBzz4T1t X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.03 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.55)[-0.554]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.96)[-0.956]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.205:from]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 17:37:56 -0000 On 2020-Oct-12, at 04:35, Klaus Cucinauomo via freebsd-arm wrote: >> Am 12.10.2020 um 01:13 schrieb Robert Crowston = : >> ... >>>> mmc0 is current device >>>=20 >>> should not be mmc0 if you boot from USB/SSD >>=20 >> I'm still using sd cards. >> ... >>=20 >> =E2=80=94 RHC. >=20 > The one and only pcie-BOSS itself is forced by armstubs to boot from a = poor 10Mb/sWrite SD-card-fingernail=E2=80=A6 > This terrible misery must end. ;-) Ha Ha, > =E2=80=A6... that=E2=80=99s why we want to use the xhci-boot feature = of 2020.10 >=20 Well, depending on what all one wants to do with the RPi4B: There is an alternative that boots via USB3 SSDs just fine (no microsd card) via modern firmware and modern .dtb files, even for 8 MiByte RPI4B's that have the MSD USB updates: uefi/ACPI v1.20 . See: https://github.com/pftf/RPi4/releases/tag/v1.20/ and the installation notes at: https://github.com/pftf/RPi4 The FreeBSD fix is known so that 3072 MiByte does not have to be selected: the full memory can be used. (Add the use of a "subtract 1" at a particular point in the the patch for handling _DMA ACPI information. See https://reviews.freebsd.org/D25219 and https://lists.freebsd.org/pipermail/freebsd-arm/2020-October/022500.html for more. I'll include the svnlite diff later below, one based on head -r365932 .) There are the tradeoffs of needing to use USB based devices for: Ethernet microsd cards (I do not know about controlling pins and such, thus the "depending on what all one wants to do".) There is also the performance tradeoff in that the uefi/ACPI context seems to ignore sdram_freq_min=3D3200 in config.txt . (Last I checked the u-boot context was putting that to use.) For reference (probable whitespace oddities from being sent via e-mail): # svnlite diff /usr/src/sys/dev/acpica/acpi.c Index: /usr/src/sys/dev/acpica/acpi.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/dev/acpica/acpi.c (revision 365932) +++ /usr/src/sys/dev/acpica/acpi.c (working copy) @@ -184,6 +184,7 @@ static void acpi_hint_device_unit(device_t acdev, device_t child, const char *name, int *unitp); static void acpi_reset_interfaces(device_t dev); +static bus_dma_tag_t acpi_get_dma_tag(device_t dev, device_t child); =20 static device_method_t acpi_methods[] =3D { /* Device interface */ @@ -218,6 +219,7 @@ DEVMETHOD(bus_hint_device_unit, acpi_hint_device_unit), DEVMETHOD(bus_get_cpus, acpi_get_cpus), DEVMETHOD(bus_get_domain, acpi_get_domain), + DEVMETHOD(bus_get_dma_tag, acpi_get_dma_tag), =20 /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), @@ -431,6 +433,123 @@ return (0); } =20 +struct dma_limits { + bus_addr_t lowaddr; +}; + +static ACPI_STATUS +dma_on_resource(ACPI_RESOURCE *res, void *arg) +{ + struct dma_limits *limits =3D arg; + bus_addr_t min, len; + + /* + * The minimum and maximum are device-side. To get the CPU-side = minimum, + * we add the translation offset. This can overflow to signify = lower addresses + * on the CPU than the device, e.g. "Bus 0xC0000000 -> CPU = 0x00000000" + * on the RPi4 is represented as 0xC0000000 min + = 0xFFFFFFFF40000000 offset. + */ + + switch (res->Type) { + case ACPI_RESOURCE_TYPE_ADDRESS16: + min =3D (uint16_t)(res->Data.Address16.Address.Minimum + + res->Data.Address16.Address.TranslationOffset); + len =3D res->Data.Address16.Address.AddressLength; + break; + case ACPI_RESOURCE_TYPE_ADDRESS32: + min =3D (uint32_t)(res->Data.Address32.Address.Minimum + + res->Data.Address32.Address.TranslationOffset); + len =3D res->Data.Address32.Address.AddressLength; + break; + case ACPI_RESOURCE_TYPE_ADDRESS64: + min =3D (uint64_t)(res->Data.Address64.Address.Minimum + + res->Data.Address64.Address.TranslationOffset); + len =3D res->Data.Address64.Address.AddressLength; + break; + case ACPI_RESOURCE_TYPE_END_TAG: + return (AE_OK); + default: + printf("ACPI: warning: DMA limit with unsupported = resource type %d\n", + res->Type); + return (AE_OK); + } + + if (min !=3D 0) + printf("ACPI: warning: DMA limit with non-zero minimum = address" + " not supported yet\n"); + + limits->lowaddr =3D MIN(limits->lowaddr, min + len); + + return (AE_OK); +} + +static int +get_dma_tag(ACPI_HANDLE handle, bus_dma_tag_t *result) +{ + ACPI_HANDLE parent; + unsigned int coherent; + struct dma_limits limits =3D { + .lowaddr =3D BUS_SPACE_MAXADDR, + }; + + if (ACPI_FAILURE(AcpiWalkResources(handle, "_DMA", + dma_on_resource, (void *)&limits))) { + /* Inherit resources from parent handle if we don't have = our own */ + if (ACPI_SUCCESS(AcpiGetParent(handle, &parent))) + return (get_dma_tag(parent, result)); + + /* The root (which has no parent) has no restrictions */ + *result =3D NULL; + return (0); + } + + if (ACPI_FAILURE(acpi_GetInteger(handle, "_CCA", &coherent))) + coherent =3D 0; + + /* + * First off, a note about lowaddr values. What sysctl showed + * me was (during investigation of u-boot/dtb/fdt oddities + * that had the same style of solution that I am trying here): + * + * . . . + * hw.busdma.zone2.lowaddr: 0x3c000fff + * . . . + * hw.busdma.zone1.lowaddr: 0x3fffffff + * . . . + * hw.busdma.zone0.lowaddr: 0xffffffff + * . . . + * + * So I've guessed that lowaddr should identify the + * end page of the possibly-use-it region, not the + * first do-not-use-it page. If I've guessed wrong, + * at most it would bounce one page that it could + * avoid bouncing. But, if I guessed correct, it + * might bounce a page that it should instead of + * not doing so. Thus the "-1" below. + */ + if (bus_dma_tag_create(NULL, 1, 0, + limits.lowaddr-1, BUS_SPACE_MAXADDR, NULL, NULL, + BUS_SPACE_MAXSIZE, BUS_SPACE_UNRESTRICTED, = BUS_SPACE_MAXSIZE, + coherent ? BUS_DMA_COHERENT : 0, NULL, NULL, + result) !=3D 0) + return (ENOMEM); + + return (0); +} + +static bus_dma_tag_t +acpi_get_dma_tag(device_t dev, device_t child) +{ + bus_dma_tag_t result; + + if (get_dma_tag(acpi_get_handle(child), &result) !=3D 0) { + device_printf(child, "could not get ACPI DMA limits\n"); + return (NULL); + } + + return (result); +} + /* * Fetch some descriptive data from ACPI to put in our attach message. */ I later found the code that means that the "-1" is required, confirming what I had guessed: sys/arm64/arm64/busdma_machdep.c 's common_bus_dma_tag_create has: common->lowaddr =3D trunc_page((vm_paddr_t)lowaddr) + (PAGE_SIZE - 1); common->highaddr =3D trunc_page((vm_paddr_t)highaddr) + (PAGE_SIZE - 1); and so forces reference to the last byte of the page identified by = lowaddr (and highaddr). Thus lowaddr needs to identify the last page that can = avoid bouncing (or earlier). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)