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

[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:
> 
>> 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 finally got back to the Rock64 and based on (whitespace possibly
> not preserved):
> 
> # more /usr/ports/sysutils/u-boot-master/files/patch-boot__bootmeth_efi.c 
> --- 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>
> 
> #define EFI_DIRNAME    "efi/boot/"
> 
> @@ -281,9 +282,12 @@ static int distro_efi_try_bootflow_files(struct udevice *dev,
>                ret = distro_efi_get_fdt_name(fname, sizeof(fname), seq);
>                if (ret == -EALREADY)
>                        bflow->flags = BOOTFLOWF_USE_PRIOR_FDT;
> -               if (!ret)
> +               if (!ret) {
> +                       /* Limit FDT files to 4MB */
> +                       size = SZ_4M;
>                        ret = bootmeth_common_read_file(dev, bflow, fname,
>                                                        fdt_addr, &size);
> +               }
>        }
> 
>        if (*fname) {
> 
> That lead to the kernel recognizing the USB3 boot
> media:
> 
> . . .
> 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 = 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=0x2<NO_6_BYTE>
> 
> However, that quirks line was the last message from the
> boot attempt.
> 
> 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. From 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/arm64.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.)

===
Mark Millard
marklmi at yahoo.com