Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)

On 2020-Oct-8, at 23:01, Mark Millard <marklmi at yahoo.com> wrote:

> 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).

Having reverted back to u-boot 2020.10 without
compatibility list adjustments and with xhci-pci
in place again, trying a 4 GiByte RPi4 without a
microsd card boots as far as the rainbow square
on the monitor but hangs there, never displaying
even the:

U-Boot 2020.10 (Oct 09 2020 - 06:50:04 +0000)

notice.

By contrast, booted via the microsd card I
can stop it in u-boot 2020.10 and see things
like:

U-Boot> usb tree
USB device tree:
  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller 
  |
  +-2  Hub (480 Mb/s, 100mA)
  |     USB2.0 Hub 
  |  
  +-3  Vendor specific (5 Gb/s, 72mA)
  |    Realtek USB 10/100/1000 LAN 000000
  |  
  +-4  Mass Storage (5 Gb/s, 0mA)
       OWC Envoy Pro mini <REPLACED>

So it gets farther with the 4 GiByte than with
the 8 GiByte.


But, for the "microsd card through kernel load"
style of boot, I've discovered that I can use the
more modern bcm2711-rpi-4-b.dtb that I use with
uefi/ACPI booting for u-boot based booting as
well. (This might have been true with the prior
2020.07 u-boot too. I did not go back and try it.)

The implication is that the older versions of
start4.elf and fixup4.dat are important for
u-boot 2020.10 for some reason: having newer ones
is what is different for failed microsd card
based boots. The start4.elf and fixup4.dat that
work with u-boot 2020.10 are too old for USB3
only based booting.


===
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]"