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

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.


===
Mark Millard
marklmi at yahoo.com