From owner-freebsd-arm@freebsd.org Fri Oct 9 03:06:14 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 530CB437569 for ; Fri, 9 Oct 2020 03:06:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6tJ4533mz3Y54 for ; Fri, 9 Oct 2020 03:06:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GHITNSsVM1kV7K65b8m1yMKNZXWtvYz8OmvSejNHgE5xsJt2QFEliRMKVeMqeCf 8g5o9sYtYIKn5D_kEvG4ExeJv_.jY1HWjwG9lXjLOGPt38Mbv5udBJ3ygR7rSUC0QHKvIMQB9BD5 oZkRP86ymIF0EQ4o_TP4h0JbWLnK3mQxVB91HhLZHCufpySmGYQzNLDD1IvSafo9aFWjniGJLe3Z G1kNDMWuqIfYmAgmhgM.CzUYZXrPfoKkN4AVK.F3DzoA2_8BqnGoq8kn0_ZvL2jCugjgY1WjhCUF rfrYoj3gUhdXnhmtUO1p8p6Pj3uP1JGOgqy21mgC98MIb_o_.Rj03tNKagCCl.4DDnf7cRQ9c_kE lEq7QLI3gAmLFkZwIiEYlatrd.rPUoVOif1.lwbxN3F6R6OV4cBhmGYhJb1SvRp1c11kcvZn1AvL 8t6uHQPufRZwG8e8isVaua5ejx.JhiRQoFT2V51QYnHN0B.aZv4lBnl3oV5mOIBrv5ghuliXRJN5 b0z3E1coOTkeA9ONmbo_cDd9ET7JYcLxY2ob99Yu2DrUlp6FAhbMFtKMhIBNhtJR7x7wIt8l.kx5 Kx6zLnFVJWRCgYZYZlzQifu4DvPXpub0w6j5l34.SUpU2_QsiSp8e35rWVg5Qm74vp7z52l3lzC4 LTNm87dvCZfgRyU14EWhjReohfENdQJwAgl8_2Hz2cnJ8WePdNqKBSw_rDVMJg4u_lT2GjUD0ZP8 O8u9kJJJPM4rVVwrb8Z_9_hW8qEgpP4u.PbidTx_KriZbSF2HYP8y115gzEh6RavTF4cNkm3_blD hmEO70paFAJWOGm_mjTX2Qs7NuPExKK6OWyJU_mbXnuDHUEusaJT15wG5nFeO3rIqGDZ68rpfLXY VcZyElGFJHpPtVDI3GGGxHCjm3yLLgCiF7vaDGAh.4TaAArV6yJsuM4KhJVJsrpvH8aDCvW2T5Q_ lcEkRiElYy2JgB9mkO4WCEbNRVi0QSPmDgBAh2ZzXf0oGGgVRJrRb9ji7G2fTxdKKycHgF4xaCPN nc5blyL1OiREUpNzj3o9LRHLGjXvXmRUXl5vdSw8OABsa0G4KFk1qSTpEhF3f5SrrYOVn2v2MuZI cnDHMB0g_TSpDEwW2pMEpLPX3NGg_iTab6dgi1UT8tcL1OTpyWeRjjVAw2DSHyyXjNNhN7buG0Ws xpb4L8iouOhTqDy0LTm7tKjUIYS45aKJwMJQNVNGXg_cGzQtueLUjh8X9l5veU26O51.Lc36dgaK hUf1ePZ1z.jTMWONrgdJoMbz04h5r53Mtgcdc83zPFO7W185BixCp4Q2s316Wy.GYUnptAUNmG1w lxvzeS5KqzixcrYlpY6Can0ZXScLE5aut4QECVzk8_Jo_0uWzbL511CL7pTnr7aWrrGt8u4tYUpY hjGWMe9ycL44ZTdDV49sVlXDH0t9CUsV6PSTMh276Ca9na2WctOqXV8qBqNGbTq67bBtZglvvUOy OfIuc1vzYRqBi1ZooyWbT_nfVfxv82GBZeRu7ZL4hcx92SjUGsRWiTc2zgglXlZe8rtSOnHynlqa cNJFCdygdZDAU.4yHTaf6mdJ2FYa5QEOY Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 03:06:10 +0000 Received: by smtp402.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4c5e1221013ea399f20f915eb005f95a; Fri, 09 Oct 2020 03:06:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Thu, 8 Oct 2020 20:06:05 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> References: To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6tJ4533mz3Y54 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.69)[-0.687]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 03:06:14 -0000 On 2020-Oct-8, at 06:27, Klaus Cucinauomo = wrote: >> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>=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)