Re: Rock64 vs. USB3 for 14.0-ALPHA2 's Rock64 snapshot vs. device tree update(?)

Hi,

On Mon, Aug 21, 2023 at 5:33 PM Emmanuel Vadot <manu@bidouilliste.com>
wrote:

>
>  Hi Guy,
>
> On Mon, 21 Aug 2023 13:37:58 +0300
> Guy Yur <guyyur@gmail.com> wrote:
>
> > Hi,
> >
> > On Sun, Aug 20, 2023 at 10:08?PM Mark Millard <marklmi@yahoo.com> wrote:
> >
> > > On Aug 20, 2023, at 11:08, Guy Yur <guyyur@gmail.com> wrote:
> > >
> > > ... (snip)
> > > >
> > > > I boot from sdcard with msdosfs partition with EFI/BOOT/bootaa64.efi
> and
> > > the dtb in rockchip/ dir in the partition.
> > > > I tested renaming the rockchip dir so the dtb won't be found and
> there
> > > was still a device tree provided.
> > > > seen in devinfo and ofwdump.
> > >
> > > Back when I established my structure (long ago) this provided
> > > U-Boot's translation of its *.dtb --which did not work for
> > > FreeBSD purposes at the time. FreeBSD's Rock64 related updates
> > > have been based on tracking upstream linux at some point.
> > > Doing what I did got the FreeBSD *.dtb that FreeBSD expected
> > > (at the time. anyway).
> > >
> > >
> > Updating with more correct information for future reference since
> > from my previous post it sounds like u-boot behavior changed when
> > it has not in regards to placing the fdt file in the EFI partition.
> >
> > The real issue is a bug in u-boot 2023.07.02 failing to read the fdt from
> > the EFI partition
> > and the u-boot provided fdt bindings for Rock64 containing wrong xhci
> > definition.
> >
> > Reading fdt file was fixed in:
> >
> https://source.denx.de/u-boot/u-boot/-/commit/2984d21a28f812c9c1fd2243cc72796f69a61585
> >
> > I believe all issues should be resolved in the next u-boot release.
>
>  Thanks for finding that, my rock64 is in a sad state (keep freezing
> even in u-boot after a few minutes, looks like power just die) so it's
> hard for me to test stuff on it. Can you confirm that adding this patch
> to u-boot-rock64 fixes everything ?
>
>
I don't currently have the Rock64 locally.
I used it to set up an openvpn site-to-site tunnel remotely so I don't have
access to it at the moment.
It is running with the previous patches I listed for fixing the u-boot dts.

Last u-boot debugging I did today was with Orange Pi R1 Plus which should
be similar (same rk3328).
I used a local u-boot port with just MODEL and BOARD_CONFIG different from
rock64.

I now recompiled u-boot with just the patch to fix reading the fdt and the
patch adding orangepi-r1-plus files.
To make it more similar, I added &usb_host0_xhci to
rk3328-orangepi-r1-plus-u-boot.dtsi to make it incorrect like
rk3328-rock64-u-boot.dtsi.

For FreeBSD 14.0-ALPHA1, I added the dts path
to sys/modules/dtb/rockchip/Makefile so it is using the FreeBSD src dts.

The Orange Pi R1 Plus booted fine, found the fdt on the EFI partition and
saw the XHCI controller.

There is an issue specific to the R1 Plus, it doesn't have an hdmi port and
doesn't enable hdmiphy in its fdt so clknode_link_recalc fails for that
clock but it doesn't prevent booting.
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9


>  Cheers,
>
> > ... (snip)
> > >
> > > I do not know if the Rock64 related support will continue to
> > > be updated to track the linux upstream updates or not. (If not,
> > > then likely snapshots and releases for Rock64 would stop.)
> > >
> > > As stands I do not plan on going down a path that might not
> > > be what FreeBSD ends up with for Rock64 related support if
> > > it is updated. For now, I've just put the Rock64 to the side.
> > > But I'm keeping copies of your notes.
> > >
> > >
> > I think the current fdt that comes with 14.0 works fine for USB3,
> > so at least for now a modern device tree should work.
> >
> > ... (snip)
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > >
> > >
> > ===
> > Guy Yur
>
>
> --
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>

--
Guy Yur