Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2020-Oct-8, at 21:29, Mark Millard <marklmi at yahoo.com> wrote: > 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: >> >>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm <[email protected]>: >>>> >>>> >>>> The old u-boot/DTB combination in use does not have emmc2bus. >>>> And, even if it did, FreeBSD would not use ………. >>> >>> … and the new 2020.10- combinations will even be more annoying… >>> 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 >>> (depending on hw-revisions)…and 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 >>> for a time period… other than leaving it crappy as is and to be happy that it nevertheless >>> is a working fbsd-gadget :-) >> >> >> Summary of probable-cause finding: u-boot 2020.10 is >> expecting: >> >> compatible = "brcm,generic-xhci" >> >> instead of what seems to be in files that are in use >> by FreeBSD: >> >> compatible = "generic-xhci" >> >> (I've no clue what all the other differences in the .dtb >> file contents might be.) >> >> >> >> The details of what I learned that reached that status . . . >> >> 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. >> >> That 8 GiByte RPi4B context booted just fine. >> >> I then rebooted and had it stop in u-boot and looked around just a little >> bit. >> >> U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) >> >> 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 >> >> So it reproted the problem above. Yet . . . >> >> 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 >> >> U-Boot> pci 1 >> Scanning PCI devices on bus 1 >> BusDevFun VendorId DeviceId Device Class Sub-Class >> _____________________________________________________________ >> 01.00.00 0x1106 0x3483 Serial bus controller 0x03 >> >> So it does see the xHCI on the pci bus despite the >> "Bus xhci_pci: probe failed, error -110". -110 looks >> to be -ETIMEDOUT . >> >> Looking at the v2020.10/drivers/usb/host/xhci-pci.c source >> code shows that the xhci_pci driver has: >> >> . . . >> static const struct udevice_id xhci_pci_ids[] = { >> { .compatible = "xhci-pci" }, >> { } >> }; >> >> U_BOOT_DRIVER(xhci_pci) = { >> .name = "xhci_pci", >> .id = UCLASS_USB, >> .probe = xhci_pci_probe, >> .remove = xhci_deregister, >> .of_match = xhci_pci_ids, >> .ops = &xhci_usb_ops, >> .platdata_auto_alloc_size = sizeof(struct usb_platdata), >> .priv_auto_alloc_size = sizeof(struct xhci_ctrl), >> .flags = DM_FLAG_ALLOC_PRIV_DMA, >> }; >> >> static struct pci_device_id xhci_pci_supported[] = { >> { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, >> {}, >> }; >> >> U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); >> >> (It looks like the above driver is used as the default >> driver if no explicit match is found. It has been around >> for years.) >> >> >> 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: >> >> xhci@7e9c0000 { >> compatible = "generic-xhci"; >> status = "disabled"; >> reg = <0x00000000 0x7e9c0000 0x00000000 0x00100000>; >> interrupts = <0x00000000 0x000000b0 0x00000004>; >> phandle = <0x000000d3>; >> }; >> >> For reference, for FreeBSD there is: >> >> # 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 = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: compatible = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: compatible = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: compatible = "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"; >> >> That FreeBSD generic_xhci_fdt.c match is from: >> >> static struct ofw_compat_data compat_data[] = { >> {"marvell,armada-380-xhci", true}, >> {"marvell,armada3700-xhci", true}, >> {"marvell,armada-8k-xhci", true}, >> {"generic-xhci", true}, >> {NULL, false} >> }; >> >> (End for-reference.) >> >> There is another driver in u-boot 2020.10, one that >> does mention "generic-" for xhci in >> drivers/usb/host/xhci-brcm.c : >> >> static const struct udevice_id xhci_brcm_ids[] = { >> { .compatible = "brcm,generic-xhci" }, >> { } >> }; >> >> U_BOOT_DRIVER(usb_xhci) = { >> .name = "xhci_brcm", >> .id = UCLASS_USB, >> .probe = xhci_brcm_probe, >> .remove = xhci_brcm_deregister, >> .ops = &xhci_usb_ops, >> .of_match = xhci_brcm_ids, >> .platdata_auto_alloc_size = sizeof(struct brcm_xhci_platdata), >> .priv_auto_alloc_size = sizeof(struct xhci_ctrl), >> .flags = DM_FLAG_ALLOC_PRIV_DMA, >> }; >> >> It is a new driver as of around 6 months ago and so is likely >> the one created for the RPi4B context. >> >> (Note the usb_xhci vs. xhci_brcm distinct namings of >> the driver.) >> >> >> 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. >> >> It seems that .dtb files that the u-boot folks expect for >> the RPi4B are vintages/variations that have compatible >> listing: "brcm,generic-xhci" . >> >> 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. >> >> 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. 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). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"