From owner-freebsd-arm@freebsd.org Fri Oct 9 06:01:45 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 1DCCB43A203 for ; Fri, 9 Oct 2020 06:01:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4C6yBb4pbkz3gJH for ; Fri, 9 Oct 2020 06:01:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8LiR12IVM1kuoztqIzbTyVmNxzDfOi1Y938N.a2lVqk6XZu7PM3xhDbD_Fz263y oFfwVkqVulHtR5Vo8rSYZLrdZEn7..tPI7.O1gggUr30a0Dboa4sSyyHmAxn_OXA254Ei4PQQMYh 8tefz3ESMewo2QjFWcKuK7Po0cUSRaZdNXS8FygVAa4dHpacs_hcNnepcNP_3opEF8rgJzqn60z_ mvoX8CYzKXnxZf8dfkPBz_6rJA74c87GjWBTj09XwcO6dseX_xsjeGMc.PdnxxZF3dMUZdv_XA8p xp4zBDYFogg_U_omNA.IPYGjNc2X4G2r6l2M84MJyIsLa29PGu2153rSAuKyG6Nj4yf2ywuq1LKK DH1yTurr.s9el3xFQEBf_xVCO9ShiVgjKEhUW259zbwCsurAPOtQeMf9EhrELL.K8v1wDKeqsyJM lyq4vb2Isurgf7sp0ooql5dYMmhrFzjZfF0Cb.ykrpuCYOU3KWV6jTbEcPOxrRPQvo_31Yg6S8wI G5ZrnV38dBsZVeuMWEgs1ztQ1003NjDbBD5RyoLyJXZ4jL.DcShwKKSXyNqMK2tTuWF9acVaQ86n duk0GUvLFpgfIn3eZnBb_ZqN6_YOuaVk7QEWxbFvah0lzTNvMV4tNyNZ6ICrN6jd2vExQUJoOLoM k3iY6AA3tZFXKZCQNMIa6t4J1Ykr2qUXXLTy5j1kOlfvTuvm.VBrllPXzAyRUg2OoBiL4GkM0hFG cSdjBVa6ooHzrbfDQX6Jz0K153ubRd8hnqGqe65LT_kz_9IUX1XQVhQBdQOSlocj0bARa8ftcgnj 8eRIhAVH3bRGQBMuiupJEHIEnSKiYIyzbKovRuoParg3aAIK0Pmq5XkpVN_dex.1NBSm0OB86d0I 7SrosEj3R_VLxsjidZLXjouk25svtNKCXWUrS90OL5XqsBJHSsR7M9z2K_Up2Tc4c3xyiHJd0HNP sA9n.XZ.L2gxA4._6DrltCRBdY1UJUBbtbaUSrEHLaJuPX19gY3uA3YXtQwC3HTIKGHjXPBK6EAF EXY3fI_mq.y33DE0s4gXtbE.eCLhzx7U3UintIA3SqzQBSR89mqp0DJIisTCgmjkrBnQ0egRd1cn BkpeI4.a4aAKRBUtDrokIO7hRxwJEyuMfuWyTsPYP9e2PrP0i9ZAxi2eeA3LOWBJ_HbUsc1Khr37 2Fa4_9003Vl7S.VTI8EmUTwAjDT6FY9cGoeFrj6C1jwSFjp_njD.kOZAIzeEj9xruIhvuJaSYhrA 2K1aPgfi.0XoK_xdxGSTcKmaIDXLkHX97OquN1EHMPcH9gzmJjeSm7QSoeO6hq0XvUOUJ2mVvOuW u9TA6BrF2ufkxvWAWj5saXVFVQqiDraaIMTN0kDzpuc7zfl2PcbToshj0KuVRbW1hc9ocHTMVrph EZE97kdJb7H192oCnbyH5VkY1lUfVVuNbj5JMrFeMZFvjgJAtSFroUQ7QylvDieP67g_KSloTz63 pyXGkiz1V6NANScZnqpGCVtsUAl5DneIOjt2DgzoE9Cs3qIBQg96AjKnoaSwYQNKAD_6CcHkpycN LQbciEvFFG0J0Ue.4ckTHVuWVFJyhuLPbTA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 06:01:42 +0000 Received: by smtp419.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65e8efc1d0c5aa858b52fe3635ef160c; Fri, 09 Oct 2020 06:01:34 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> Date: Thu, 8 Oct 2020 23:01:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6yBb4pbkz3gJH X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.56 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.05)[-1.054]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.01)[-1.010]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; 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: Fri, 09 Oct 2020 06:01:45 -0000 On 2020-Oct-8, at 21:29, Mark Millard wrote: > On 2020-Oct-8, at 20:06, Mark Millard wrote: >=20 >> On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >>=20 >>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>>=20 >>>>=20 >>>> The old u-boot/DTB combination in use does not have emmc2bus. >>>> And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6= . >>>=20 >>> =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 >>> While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, >>> Depending on GUESSED ;-) combinations and DeviceTree-patches in src = . >>> There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 >>> (depending on hw-revisions)=E2=80=A6and so on ... >>> I doubt that anyone really will take explicitly time consuming care = of all that annoying RPI4-crap. >>> I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 >>> for a time period=E2=80=A6 other than leaving it crappy as is and = to be happy that it nevertheless=20 >>> is a working fbsd-gadget :-) >>=20 >>=20 >> Summary of probable-cause finding: u-boot 2020.10 is >> expecting: >>=20 >> compatible =3D "brcm,generic-xhci" >>=20 >> instead of what seems to be in files that are in use >> by FreeBSD: >>=20 >> compatible =3D "generic-xhci" >>=20 >> (I've no clue what all the other differences in the .dtb >> file contents might be.) >>=20 >>=20 >>=20 >> The details of what I learned that reached that status . . . >>=20 >> I updated my ports environment on a RPi4 to build the final 2020.10 = u-boot >> for the RPi4. I then built it and replaced the u-boot.bin on the = microsd >> card that I boot with via the FreeBSD kernel being from that microsd = card >> but later stages being from the USB3 SSD. I did not update anything = else. >> So: still an older .dtb file. >>=20 >> That 8 GiByte RPi4B context booted just fine. >>=20 >> I then rebooted and had it stop in u-boot and looked around just a = little >> bit. >>=20 >> U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) >>=20 >> DRAM: 7.9 GiB >> RPI 4 Model B (0xd03114) >> MMC: mmc@7e300000: 1, emmc2@7e340000: 0 >> Loading Environment from FAT... In: serial >> Out: vidconsole >> Err: vidconsole >> Net: eth0: ethernet@7d580000 >> PCIe BRCM: link up, 5.0 Gbps x1 (SSC) >> starting USB... >> Bus xhci_pci: probe failed, error -110 >> No working controllers found >> Hit any key to stop autoboot: 0=20 >>=20 >> So it reproted the problem above. Yet . . . >>=20 >> U-Boot> pci 0 >> Scanning PCI devices on bus 0 >> BusDevFun VendorId DeviceId Device Class Sub-Class >> _____________________________________________________________ >> 00.00.00 0x14e4 0x2711 Bridge device 0x04 >>=20 >> U-Boot> pci 1 =20 >> Scanning PCI devices on bus 1 >> BusDevFun VendorId DeviceId Device Class Sub-Class >> _____________________________________________________________ >> 01.00.00 0x1106 0x3483 Serial bus controller 0x03 >>=20 >> So it does see the xHCI on the pci bus despite the >> "Bus xhci_pci: probe failed, error -110". -110 looks >> to be -ETIMEDOUT . >>=20 >> Looking at the v2020.10/drivers/usb/host/xhci-pci.c source >> code shows that the xhci_pci driver has: >>=20 >> . . . >> static const struct udevice_id xhci_pci_ids[] =3D { >> { .compatible =3D "xhci-pci" }, >> { } >> }; >>=20 >> U_BOOT_DRIVER(xhci_pci) =3D { >> .name =3D "xhci_pci", >> .id =3D UCLASS_USB, >> .probe =3D xhci_pci_probe, >> .remove =3D xhci_deregister, >> .of_match =3D xhci_pci_ids, >> .ops =3D &xhci_usb_ops, >> .platdata_auto_alloc_size =3D sizeof(struct usb_platdata), >> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >> }; >>=20 >> static struct pci_device_id xhci_pci_supported[] =3D { >> { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, >> {}, >> }; >>=20 >> U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); >>=20 >> (It looks like the above driver is used as the default >> driver if no explicit match is found. It has been around >> for years.) >>=20 >>=20 >> But, in the past when I showed the likes of fdt print / >> or translation to a .dts file, it did not have "xhci-pci" >> in compatible but had "generic-xhci" instead, such as: >>=20 >> xhci@7e9c0000 { >> compatible =3D "generic-xhci"; >> status =3D "disabled"; >> reg =3D <0x00000000 0x7e9c0000 0x00000000 = 0x00100000>; >> interrupts =3D <0x00000000 0x000000b0 = 0x00000004>; >> phandle =3D <0x000000d3>; >> }; >>=20 >> For reference, for FreeBSD there is: >>=20 >> # grep -ri "xhci-pci" /usr/src/sys/ | more >> # grep -ri "generic-xhci" /usr/src/sys/ | more >> /usr/src/sys/dev/usb/controller/generic_xhci_fdt.c: = {"generic-xhci", true}, >> /usr/src/sys/gnu/dts/arm/bcm-nsp.dtsi: compatible =3D = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-37xx.dtsi: = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >>=20 >> That FreeBSD generic_xhci_fdt.c match is from: >>=20 >> static struct ofw_compat_data compat_data[] =3D { >> {"marvell,armada-380-xhci", true}, >> {"marvell,armada3700-xhci", true}, >> {"marvell,armada-8k-xhci", true}, >> {"generic-xhci", true}, >> {NULL, false} >> }; >>=20 >> (End for-reference.) >>=20 >> There is another driver in u-boot 2020.10, one that >> does mention "generic-" for xhci in >> drivers/usb/host/xhci-brcm.c : >>=20 >> static const struct udevice_id xhci_brcm_ids[] =3D { >> { .compatible =3D "brcm,generic-xhci" }, >> { } >> }; >>=20 >> U_BOOT_DRIVER(usb_xhci) =3D { >> .name =3D "xhci_brcm", >> .id =3D UCLASS_USB, >> .probe =3D xhci_brcm_probe, >> .remove =3D xhci_brcm_deregister, >> .ops =3D &xhci_usb_ops, >> .of_match =3D xhci_brcm_ids, >> .platdata_auto_alloc_size =3D sizeof(struct = brcm_xhci_platdata), >> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >> }; >>=20 >> It is a new driver as of around 6 months ago and so is likely >> the one created for the RPi4B context. >>=20 >> (Note the usb_xhci vs. xhci_brcm distinct namings of >> the driver.) >>=20 >>=20 >> The .dtb files that I use for uefi/ACPI booting of FreeBSD >> and for u-boot based booting of ubuntu 2010.04.1 also use >> "generic-xhci", no "brcm," invovled. >>=20 >> It seems that .dtb files that the u-boot folks expect for >> the RPi4B are vintages/variations that have compatible >> listing: "brcm,generic-xhci" . >>=20 >> If one finds a .dtb with such, it might be close to what >> they were testing. With such a file, finding other >> differences with the .dtb files currently in use with >> FreeBSD could be done. >>=20 >> I hope that the above helps. >=20 > Looks like the u-boot.bin built includes "xhci-pci" > but excludes "brcm,generic-xhci": not in the output > of hd /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin > after the port is installed. >=20 > My initial guess would be that something more needs > to be specified to cause drivers/usb/host/xhci-brcm.c > (and possibly more) to be built and included. Looks like that was a bad guess, it still gets: No working controllers found based on instead having the "brcm,generic-xhci" driver (with a "generic-xhci" added to the compatibility list). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)