RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Mark Millard
marklmi at yahoo.com
Fri Oct 9 06:01:45 UTC 2020
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 <freebsd-arm at freebsd.org>:
>>>>
>>>>
>>>> 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 at 7e300000: 1, emmc2 at 7e340000: 0
>> Loading Environment from FAT... In: serial
>> Out: vidconsole
>> Err: vidconsole
>> Net: eth0: ethernet at 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 at 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)
More information about the freebsd-arm
mailing list