Re: Booting rock64 from USB SSD

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 2022-Apr-1, at 06:51, Łukasz Moskała <[email protected]> wrote:

> Hi everyone,
> 
> I want to boot my rock64 from SSD (because all sd cards I could find are crap).
> 
> I followed those instructions to flash u-boot to SPI: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md
> 
> I was then able to boot FreeBSD from SSD (dd FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SSD, just like it would be to SD card), but ethernet wasn't working. Actually, it could receive packets but no outgoing packets were sent. Not even ARP packets - switch didn't detect any device on that port, but link was UP
> 
> I assumed it was something to do with u-boot, so I erased u-boot from flash, then DD FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SD card, and it worked without problems.
> 
> Do I understand correctly that this means that FreeBSD on rock64 uses custom u-boot? Can I somehow flash it to SPI?
> 
> Possible workaround that I can think of would be to put /boot on sd card, install u-boot to sd card, then put / on SSD.

My memory is that USB2 booting could be more normal, in that the
U-Boot from ports could access USB2 storage but not USB3 storage,
at least when I set this up long ago. I wanted USB3 use, thus the
below details.

I have U-Boot on the /media/ device below. As I remember, it could not
deal with the USB3 port, which is the one I wanted to use. The
FreeBSD kernel was the first stage that could deal with the USB3 port
back when I set up the Rock64 that I have access to.

I've not had to change the basic structure since I set it up. There
could be aspects that could be different these days and I'd not know.
Think of any comments as potentially being old information.

Note: mmcsd0 here is actually an eMMC device instead of the microsd
card slot contents, leaving the microsd card slot free for other uses.
But I'd used a microsd card this way before using the eMMC device
(as I remember anyway).

# gpart show -p
=>       63  244277185    mmcsd0  MBR  (116G)
         63      32705            - free -  (16M)
      32768     102312  mmcsd0s1  fat32lba  [active]  (50M)
     135080      28760            - free -  (14M)
     163840  241172480  mmcsd0s2  freebsd  (115G)
  241336320    2940928            - free -  (1.4G)

=>        0  241172480   mmcsd0s2  BSD  (115G)
          0  230686720  mmcsd0s2a  freebsd-ufs  (110G)
  230686720   10485760             - free -  (5.0G)

=>        40  1953525088    da0  GPT  (932G)
          40      532480  da0p1  efi  (260M)
      532520        2008         - free -  (1.0M)
      534528     7340032  da0p2  freebsd-swap  (3.5G)
     7874560     1048576         - free -  (512M)
     8923136    23068672  da0p3  freebsd-swap  (11G)
    31991808     2097152         - free -  (1.0G)
    34088960    33554432  da0p4  freebsd-swap  (16G)
    67643392  1740636160  da0p5  freebsd-ufs  (830G)
  1808279552     4194304  da0p6  freebsd-swap  (2.0G)
  1812473856   141051272         - free -  (67G)

For reference, from "gpart show -pl" :

    67643392  1740636160  da0p5  Rock64root  (830G)

(The USB drive can boot other systems as well, with
widely varying amounts of RAM. Thus the efi partition
and the odd set of freebsd-swap partitions.)

So, /media/ below is mmcsd0s1's fat32lba and /mnt/ is
mmcsd0s2a's freebsd-ufs. da0 is the USB3 SSD media,
which I do not give other details of here. (I manually
mounted these for this note.)

# ls -Tld /media/*/*/* /mnt/* /mnt/etc/*
-r-xr-xr-x   1 root  wheel  1243772 Jan 28 12:33:00 2022 /media/EFI/BOOT/bootaa64.efi
-r-xr-xr-x   1 root  wheel    50618 Jan 28 12:32:28 2022 /media/dtb/rockchip/rk3328-rock64.dtb
-r--r--r--   1 root  wheel     6170 Feb  1 04:48:34 2020 /mnt/COPYRIGHT
drwxr-xr-x  23 root  wheel     1536 Jan 28 15:26:41 2022 /mnt/boot
drwxr-xr-x   2 root  wheel      512 Apr 26 14:39:22 2020 /mnt/etc
-rw-r--r--   1 root  wheel       37 Dec 31 16:00:18 2009 /mnt/etc/hostid
drwx------   2 root  wheel    33280 Nov 27 09:46:08 2019 /mnt/lost+found

# ls -Tld /mnt/boot/dtb/overlays/rk3328-*
-r--r--r--  1 root  wheel   238 Jan 28 12:32:28 2022 /mnt/boot/dtb/overlays/rk3328-analog-sound.dtbo
-r--r--r--  1 root  wheel  1281 Jan 28 12:32:28 2022 /mnt/boot/dtb/overlays/rk3328-dwc3.dtbo

(I make no use of rk3328-analog-sound.dtbo .)

/mnt/boot/loader.conf has, in part,

# A msdosfs /MNTPNT/dtb/rockchip/rk3328-rock64.dtb
# copy of the ufs /boot/dtb/rockchip/rk3328-rock64.dtb
# uses the intended DTB in u-boot and the kernel --and
# avoids needing to tell the kernel where to find a
# copy . . .
#rk3328_rock64_load="YES"
#rk3328_rock64_type="dtb"
#rk3328_rock64_name="/boot/dtb/rockchip/rk3328-rock64.dtb"
#
# rk3328 USB3-related:
fdt_overlays="rk3328-dwc3.dtbo"
# ucom is not automatically being loaded when umodem is loaded at boot.
ucom_load="YES"
umodem_load="YES"
#
vfs.root.mountfrom="ufs:/dev/gpt/Rock64root"
kern.cam.boot_delay=10000
vfs.mountroot.timeout=10
vfs.root_mount_always_wait=1

===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.