Date: Thu, 8 Oct 2020 21:29:25 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> In-Reply-To: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> <ABE16EA6-49F1-461F-9B8A-6DAA7ED6A18D@googlemail.com> <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-8, at 20:06, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Oct-8, at 06:27, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: >=20 >>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org>: >>>=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. 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. 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. =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?91324D35-B66A-4674-AE37-45F3DDB736FD>