From nobody Mon Aug 21 19:50:44 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RV34f3wBCz4rFDt for ; Mon, 21 Aug 2023 19:50:58 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RV34d5Q9Cz4W83 for ; Mon, 21 Aug 2023 19:50:57 +0000 (UTC) (envelope-from guyyur@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=DSYd8AhQ; spf=pass (mx1.freebsd.org: domain of guyyur@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=guyyur@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-991c786369cso497060666b.1 for ; Mon, 21 Aug 2023 12:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692647456; x=1693252256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xFN1eid6wR9dHDqTDUGV1K48+kCkwWN6S5vSPlSvL0s=; b=DSYd8AhQkGZ+1cJ1XROW7B/xHzQmCSw6aSZ80fgUylLY4kEOclMpZKN1uLQGVJhaso MGFibmgF6QlqrZwsH4DZAYry7GUlG8AJDxwU79uevFpJOdmjHJuszpntBL9wNCeTXOub HUCVn3lFrSMnk1UGjspl/I1loaUW1pJSQJbbzZrpLp3CabGniXyadbBeN/vJCrirzaNi 67s9v2OrWrPUEarkmPOUBHaybPCG/TZuz2fqR3fjBaJWy+Pzwcrmzd4f1kJtqIQUnrxW dOC4MQ88jmuxq9Pq+7U5Z20Ro6Xo1nLFSVbuE6IEMqU499jfCO0gRyyTmEg3A0cZ8ra1 h3oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692647456; x=1693252256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xFN1eid6wR9dHDqTDUGV1K48+kCkwWN6S5vSPlSvL0s=; b=D01LSIl1BD23s9vV/CnTboyIuW3mitFhnNjV7bINvvRNUGQL4CY5DyDCohZnWEUBVu +Qp8LPP7l8ge7VZn7tfIaLVzAE5R2p+X2882R+byQ2d2MOTqUBctxUaqfJR2ES1waQ/V ZOrSX7MbxdMGLpllwEFjWnjZrQgA8bhtmb/q1pnZ+Co0NHxlcAW6yPIp4EhtBYgEL+n3 xXRaBYodH2Wj/iHYWxhKzfmbXrBwqSqqj8j1Wqs4R5+3e5BUZ8kfGuqxCxaWljohAdnv gF6Rxyx211myp/Du4Ry8GnPVIkHj9e+x8CPpUpaNQssV417n4bUzucCEWTK+f67dDYm+ 9ePQ== X-Gm-Message-State: AOJu0YyMYSCANu++2WvO016FJS2uM0ecmnDt6EG8VolltTgKlQecLQAF dN1PZcsSj3jqeCQviwHC1NSbA9brAtWW0VXWeGA= X-Google-Smtp-Source: AGHT+IFMugsOdU6rhCVkMYIVDof4QW8cCyqmLHgOkzHrYgQ4I4Z5hXP87ot58+QHkgYADzYFxXwOjPRBzv28vSCf3qE= X-Received: by 2002:a17:906:73da:b0:994:569b:61b8 with SMTP id n26-20020a17090673da00b00994569b61b8mr5470223ejl.58.1692647455742; Mon, 21 Aug 2023 12:50:55 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <20230821163318.20c8e582db7000d3b6a8412d@bidouilliste.com> In-Reply-To: <20230821163318.20c8e582db7000d3b6a8412d@bidouilliste.com> From: Guy Yur Date: Mon, 21 Aug 2023 22:50:44 +0300 Message-ID: Subject: Re: Rock64 vs. USB3 for 14.0-ALPHA2 's Rock64 snapshot vs. device tree update(?) To: Emmanuel Vadot Cc: Mark Millard , freebsd-arm Content-Type: multipart/alternative; boundary="000000000000545e4f0603743211" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::634:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; ARC_NA(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RV34d5Q9Cz4W83 --000000000000545e4f0603743211 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 21, 2023 at 5:33=E2=80=AFPM Emmanuel Vadot wrote: > > Hi Guy, > > On Mon, 21 Aug 2023 13:37:58 +0300 > Guy Yur wrote: > > > Hi, > > > > On Sun, Aug 20, 2023 at 10:08?PM Mark Millard wrote= : > > > > > On Aug 20, 2023, at 11:08, Guy Yur wrote: > > > > > > ... (snip) > > > > > > > > I boot from sdcard with msdosfs partition with EFI/BOOT/bootaa64.ef= i > 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 fr= om > > 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/2984d21a28f812c9c1fd2243cc7= 2796f69a61585 > > > > 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) > > > > > > =3D=3D=3D > > > Mark Millard > > > marklmi at yahoo.com > > > > > > > > =3D=3D=3D > > Guy Yur > > > -- > Emmanuel Vadot > -- Guy Yur --000000000000545e4f0603743211 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Aug 21, 2023 at 5:33=E2=80=AFPM Emmanuel V= adot <manu@bidouilliste.com= > wrote:

=C2=A0Hi Guy,

On Mon, 21 Aug 2023 13:37:58 +0300
Guy Yur <guyyur@gm= ail.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/boot= aa64.efi and
> > the dtb in rockchip/ dir in the partition.
> > > I tested renaming the rockchip dir so the dtb won't be f= ound 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 update= s
> > 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 f= rom
> the EFI partition
> and the u-boot provided fdt bindings for Rock64 containing wrong xhci<= br> > definition.
>
> Reading fdt file was fixed in:
> https://s= ource.denx.de/u-boot/u-boot/-/commit/2984d21a28f812c9c1fd2243cc72796f69a615= 85
>
> I believe all issues should be resolved in the next u-boot release.
=C2=A0Thanks 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<= br> 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= =C2=A0I 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 simi= lar (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-r= 1-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=C2= =A0sys/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 Pl= us, 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= =C2=A0booting.
clknode_link_recalc: Attempt to use unresolved linked clo= ck: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
<= div>=C2=A0
=C2=A0Cheers,

> ... (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)
> >
> > =3D=3D=3D
> > Mark Millard
> > marklmi at yahoo.com
> >
> >
> =3D=3D=3D
> Guy Yur


--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

--
Guy Yur=C2=A0
--000000000000545e4f0603743211--