Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks like dtb changes invalidating use of the old .dtbo and needing kernel changes)
- Reply: Mark Millard : "Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks like dtb changes invalidating use of the old .dtbo and needing kernel changes)"
- In reply to: Mark Millard : "Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks like dtb changes invalidating use of the old .dtbo and needing kernel changes)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 16 Nov 2022 10:33:53 UTC
On Tue, 15 Nov 2022 15:06:24 -0800 Mark Millard <marklmi@yahoo.com> wrote: > On Nov 15, 2022, at 13:12, Emmanuel Vadot <manu@bidouilliste.com> wrote: > > > On Tue, 15 Nov 2022 13:03:45 -0800 > > Mark Millard <marklmi@yahoo.com> wrote: > > > >> On Nov 15, 2022, at 05:05, Emmanuel Vadot <manu@bidouilliste.com> wrote: > >> > >>> On Fri, 4 Nov 2022 12:31:51 -0700 > >>> Mark Millard <marklmi@yahoo.com> wrote: > >>> > >>>> On 2022-Oct-22, at 23:00, Mark Millard <marklmi@yahoo.com> wrote: > >>>> > >>>>> Well, turns out that part of the "Import device-tree files > >>>>> from Linux 5.14" is: > >>>>> > >>>>> https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts?id=5956d97f4b32 > >>>>> > >>>>> which has: > >>>>> . . . > >>>> > >>>> > >>> > >>> Hi Mark, > >>> > >>> See https://reviews.freebsd.org/D37392 (and child reviews) for a fix. > >>> This was indeed the import of the new DTS files that caused the first > >>> problem (there is no glue node in rk3328.dtsi like in other SoCs or > >>> like our overlay). The other commit responsible for breaking USB3 > >>> support was the addition to RK356x SoC, the check was bad for when to > >>> force USB2. > >> > >> Thanks. > >> > >> I applied the diff and the 2 child diff's and rebuilt and > >> installed, including updating the kernel on the e.MMC that > >> is historically used to mount the rootfs on USB3 when the > >> USB3 drive is plugged in there. (U-boot does not handle > >> the USB context I want.) > >> > >> . . . > >> > >> > > > > Looks like you're missing https://reviews.freebsd.org/D37394 > > Hopefully this time I have all the childern, grandchildern, etc. > Sorry for the screwup. > > But the behavior observed is unchanged in this attempt. > > A diff of the console output of booting via USB2 this time > vs. the prior report's USB3 failure log reveals no differences > between the latter part of the block of: > > clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy > Cannot get frequency for clk: hdmi_phy, error: 9 That's not related. > and the later: > > Trying to mount root from ufs:/dev/gpt/Rock64root []... > uhub2: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > > No DWC3, XHCI, etc. > > But a boot -v does report: > > ofwbus0: <usb@ff600000> mem 0xff600000-0xff6fffff irq 50 compat rockchip,rk3328-xhci (no driver attached) > > Note the "xhci" instead of "dwc3". There is no such thing as rockchip,rk3328-xhci in our dts but there is one in the embbeded u-boot one, you likely don't have a correct DTB on the msdos partition. Cheers, -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>