Booting from USB on RPI3

Mark Millard marklmi at yahoo.com
Thu Apr 23 22:49:13 UTC 2020


On 2020-Apr-23, at 14:20, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Apr-23, at 13:32, Jonathan Chen <jonc at chen.org.nz> wrote:
> 
>> On Fri, 24 Apr 2020 at 08:22, Mark Millard <marklmi at yahoo.com> wrote:
>> [...]
>>> The RPi3 will not start to boot from a gpt partitioned
>>> media. So picking gpt labeling as the example is somewhat
>>> misleading for single-media booting. glabel based
>>> labeling would be more realistic for the context.
> 
> Note the "single-media booting" reference above.
> 
>> The OP is attempting to boot off an external USB drive via loader.env.
>> So it's the external drive's partitioning system that is of interest.
>> FYI, my RPI3 boots off a GPT partition fine:
>> 
>> 1.topaz:~,8:30am# uname -a
>> FreeBSD topaz.inside.chen.org.nz 12.1-STABLE FreeBSD 12.1-STABLE #0
>> r358927: Sun Mar 15 22:24:30 NZDT 2020
>> jonc at onyx.inside.chen.org.nz:/xbuilds/rpi3/obj/usr/src/arm64.aarch64/sys/GENERIC
>> arm64
>> 1.topaz:~,8:30am# gpart show -l da0
>> =>       40  976773088  da0  GPT  (466G)
>>        40       8152       - free -  (4.0M)
>>      8192  964689920    1  topaz-root  (460G)
>> 964698112   12075016    2  topaz-swap  (5.8G)
>> 
>> 1.topaz:~,8:30am# cat /etc/fstab
>> # Device                Mountpoint      FStype  Options         Dump    Pass#
>> /dev/gpt/topaz-root     /               ufs     rw              1       1
>> /dev/gpt/topaz-swap     none            swap    sw              0       0
>> 
> 
> That does not appear to have the msdosfs/EFI material
> on the USB drive. So I'd guess that you are using
> the microsd card for that: 2 media overall, not
> single-media.
> 
> I also use a form of two-media instead of single-media
> and use gpt on the USB media:
> 
> # gpart show
> =>       63  249737153  mmcsd0  MBR  (119G)
>         63      16380          - free -  (8.0M)
>      16443     131040       1  fat32lba  [active]  (64M)
>     147483        997          - free -  (499K)
>     148480  241172480       2  freebsd  (115G)
>  241320960    8416256          - free -  (4.0G)
> 
> =>        0  241172480  mmcsd0s2  BSD  (115G)
>          0  230686720         1  freebsd-ufs  (110G)
>  230686720   10485760            - free -  (5.0G)
> 
> =>       40  468862048  da0  GPT  (224G)
>         40       2008       - free -  (1.0M)
>       2048  413138944    1  freebsd-ufs  (197G)
>  413140992    6291456    2  freebsd-swap  (3.0G)
>  419432448    6291456    4  freebsd-swap  (3.0G)
>  425723904   43138184       - free -  (21G)
> 
> # df -m
> Filesystem               1M-blocks  Used  Avail Capacity  Mounted on
> /dev/gpt/PINE642Groot       195378 34775 144973    19%    /
> devfs                            0     0      0   100%    /dev
> /dev/label/PINE64P2Groot    109101   219 100153     0%    /microsd_ufs
> /dev/label/PINE642GAboot        63    43     20    69%    /boot/efi
> 
> I choose to have a copy of /boot on /microsd_ufs
> and to use vfs.root.mountfrom="ufs:/dev/gpt/PINE642Groot"
> in the loader.conf file in my context.
> 
> But such is not what Bob P. is trying to do from what
> I can tell. He looks to be trying to avoid microsd
> card media use if he can. He needs MBR on the USB
> media for that (or some hybrid MBR that proves
> compatibile).

Correcting my mistaken memory of what raspberrypi.org documents . . .

The BCM2837 (RPi3) and BCM2837B0 (RPi3B) have documentation at:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md

that does report:

	• The boot ROM also now supports GUID partitioning and has been tested with hard drives partitioned using Mac, Windows, and Linux.


It also notes (prior to the above):

	• It is no longer necessary for the first partition to be the FAT partition, as the MSD boot will continue to search for a FAT partition beyond the first one.

(I guess MSD is short for "mass storage device".)

It also documents that for USB hubs these RPi3* vintages
do recurse for each port.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list