Date: Thu, 8 Oct 2020 20:06:05 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> In-Reply-To: <ABE16EA6-49F1-461F-9B8A-6DAA7ED6A18D@googlemail.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> <ABE16EA6-49F1-461F-9B8A-6DAA7ED6A18D@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 :-)
Summary of probable-cause finding: u-boot 2020.10 is
expecting:
compatible =3D "brcm,generic-xhci"
instead of what seems to be in files that are in use
by FreeBSD:
compatible =3D "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=20
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 =20
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[] =3D {
{ .compatible =3D "xhci-pci" },
{ }
};
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,
};
static struct pci_device_id xhci_pci_supported[] =3D {
{ 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 =3D "generic-xhci";
status =3D "disabled";
reg =3D <0x00000000 0x7e9c0000 0x00000000 =
0x00100000>;
interrupts =3D <0x00000000 0x000000b0 =
0x00000004>;
phandle =3D <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 =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";
That FreeBSD generic_xhci_fdt.c match is from:
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}
};
(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[] =3D {
{ .compatible =3D "brcm,generic-xhci" },
{ }
};
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,
};
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.
=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?98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF>