Date: Fri, 1 Apr 2022 13:52:34 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?=C5=81ukasz_Moska=C5=82a?= <lm@lukaszmoskala.pl> Cc: freebsd-arm@freebsd.org Subject: Re: Booting rock64 from USB SSD Message-ID: <83A1232D-38B7-46E1-8991-043AAC36CE42@yahoo.com> In-Reply-To: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl> References: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-1, at 06:51, =C5=81ukasz Moska=C5=82a <lm@lukaszmoskala.pl> = wrote: > Hi everyone, >=20 > I want to boot my rock64 from SSD (because all sd cards I could find = are crap). >=20 > I followed those instructions to flash u-boot to SPI: = https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi= .md >=20 > 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 >=20 > 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. >=20 > Do I understand correctly that this means that FreeBSD on rock64 uses = custom u-boot? Can I somehow flash it to SPI? >=20 > 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 =3D> 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) =3D> 0 241172480 mmcsd0s2 BSD (115G) 0 230686720 mmcsd0s2a freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) =3D> 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=3D"YES" #rk3328_rock64_type=3D"dtb" #rk3328_rock64_name=3D"/boot/dtb/rockchip/rk3328-rock64.dtb" # # rk3328 USB3-related: fdt_overlays=3D"rk3328-dwc3.dtbo" # ucom is not automatically being loaded when umodem is loaded at boot. ucom_load=3D"YES" umodem_load=3D"YES" # vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root" kern.cam.boot_delay=3D10000 vfs.mountroot.timeout=3D10 vfs.root_mount_always_wait=3D1 =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?83A1232D-38B7-46E1-8991-043AAC36CE42>