Date: Sun, 27 Aug 2023 16:18:24 -0700 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Guy Yur <guyyur@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Rock64 vs. USB3 for 14.0-ALPHA2 's Rock64 snapshot vs. device tree update(?) Message-ID: <81184025-2B2E-4093-87F4-3990D7571FFA@yahoo.com> In-Reply-To: <0482D0E1-01F8-4C9B-B7C8-87EE6A7E0035@yahoo.com> References: <D6FF636E-EF88-4D74-89B6-01CF37882CD9.ref@yahoo.com> <D6FF636E-EF88-4D74-89B6-01CF37882CD9@yahoo.com> <CAC67Hz-HwHoWX1685CyCfM5uE%2BFqMzQ29hMMC9wDHDn8qHeHQg@mail.gmail.com> <E68DED8A-17E2-4AC3-A564-5F9C331231F6@yahoo.com> <CAC67Hz9C1JTEyDN=WEU6jvdx_GQ6=xKV4BHnZvytuesEkHNS2w@mail.gmail.com> <C072DEA1-3CC7-494F-8306-7A8A6CB81C0B@yahoo.com> <CAC67Hz8tu9FhH=yZLzgcLa-RH0W=4_1TqAnEY%2BRmKuETK8Mwsg@mail.gmail.com> <20230821163318.20c8e582db7000d3b6a8412d@bidouilliste.com> <0482D0E1-01F8-4C9B-B7C8-87EE6A7E0035@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[It works.] On Aug 27, 2023, at 15:07, Mark Millard <marklmi@yahoo.com> wrote: > On Aug 21, 2023, at 07:33, Emmanuel Vadot <manu@bidouilliste.com> = wrote: >=20 >> On Mon, 21 Aug 2023 13:37:58 +0300 >> Guy Yur <guyyur@gmail.com> wrote: >>=20 >>> Hi, >>>=20 >>> On Sun, Aug 20, 2023 at 10:08?PM Mark Millard <marklmi@yahoo.com> = wrote: >>>=20 >>>> On Aug 20, 2023, at 11:08, Guy Yur <guyyur@gmail.com> wrote: >>>>=20 >>>> ... (snip) >>>>>=20 >>>>> 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. >>>>=20 >>>> 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). >>>>=20 >>>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Reading fdt file was fixed in: >>> = https://source.denx.de/u-boot/u-boot/-/commit/2984d21a28f812c9c1fd2243cc72= 796f69a61585 >>>=20 >>> I believe all issues should be resolved in the next u-boot release. >>=20 >> 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 ? >=20 > I finally got back to the Rock64 and based on (whitespace possibly > not preserved): >=20 > # more = /usr/ports/sysutils/u-boot-master/files/patch-boot__bootmeth_efi.c=20 > --- boot/bootmeth_efi.c > +++ boot/bootmeth_efi.c > @@ -21,6 +21,7 @@ > #include <mmc.h> > #include <net.h> > #include <pxe_utils.h> > +#include <linux/sizes.h> >=20 > #define EFI_DIRNAME "efi/boot/" >=20 > @@ -281,9 +282,12 @@ static int distro_efi_try_bootflow_files(struct = udevice *dev, > ret =3D distro_efi_get_fdt_name(fname, sizeof(fname), = seq); > if (ret =3D=3D -EALREADY) > bflow->flags =3D BOOTFLOWF_USE_PRIOR_FDT; > - if (!ret) > + if (!ret) { > + /* Limit FDT files to 4MB */ > + size =3D SZ_4M; > ret =3D bootmeth_common_read_file(dev, bflow, = fname, > fdt_addr, = &size); > + } > } >=20 > if (*fname) { >=20 > That lead to the kernel recognizing the USB3 boot > media: >=20 > . . . > Trying to mount root from ufs:/dev/gpt/rootfs []... > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > mmcsd0: Error indicated: 4 Failed > uhub0: 1 port with 1 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub2: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > ugen4.2: <vendor 0x04e8 product 0x4001> at usbus4 > umass0 on uhub3 > umass0: <vendor 0x04e8 product 0x4001, class 0/0, rev 3.20/1.00, addr = 1> on usbus4 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0: Attached to scbus0 > random: unblocking device. > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device > da0: Serial Number *REDACTED* > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=3D0x2<NO_6_BYTE> >=20 > However, that quirks line was the last message from the > boot attempt. >=20 > I'll try to update the Rock64 media in booting for how I've > historically done it to where I've synchronized to main [so: > 15] to see what the status is there. I had made some sort of snafu previously. Re-updating the materials on the e.MMC lead to booting continuing after the quirks line as well. =46rom after login: # uname -apKU FreeBSD R64-RPi-4-3-2v1p2 15.0-CURRENT FreeBSD 15.0-CURRENT aarch64 = 1500000 #87 main-n265027-2f06449d6429-dirty: Fri Aug 25 09:20:28 PDT = 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1500000 1500000 So, overall, also using /usr/ports/sysutils/u-boot-master/files/patch-boot__bootmeth_efi.c lead to the Rock64 USB3 being operational again via the FreeBSD kernel, including for post-kernel booting. (Sequencing complicated by also updating to 15 in the mix.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81184025-2B2E-4093-87F4-3990D7571FFA>