Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Dec 2017 16:40:30 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        Freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Fairly minimal sdcard content for booting kernel and world on an RPI2 V1.1 from a USB SSD instead of from the sdcard [corrections]
Message-ID:  <90C085CE-25D6-4490-8221-7C5C2988BDD5@dsl-only.net>
In-Reply-To: <72C5DCE8-2B63-4F23-94B4-5C74E47CF89C@dsl-only.net>
References:  <96279C4C-C713-48E1-AD5F-178852C04B45@dsl-only.net> <72C5DCE8-2B63-4F23-94B4-5C74E47CF89C@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
[History deleted. Starting over.]

I still had the usdcard (mmcsd0) overcomplicated.
Starting again. . .

First off, here is what ubldr.bin shows for
devinfo when a couple of USB SSD sticks are on a
powered hub as well:

loader> devinfo
U-Boot devices:
device info (0):
  cookie        =3D 0x3af5e4d0
  type          =3D 0x00000042
  type          =3D USB
  blk size              =3D 512
  blk count             =3D 468862128

device info (1):
  cookie        =3D 0x3af5e670
  type          =3D 0x00000042
  type          =3D USB
  blk size              =3D 512
  blk count             =3D 468862128

device info (2):
  cookie        =3D 0x3af5d440
  type          =3D 0x00000082
  type          =3D MMC
  blk size              =3D 512
  blk count             =3D 62521344

The (<unit>) for the MMC changes from boot
to boot if the number of USB drives is
changed from boot to boot. The assigned
<unit>'s units for USB depends on the
pattern of what USB drives are plugged in
where.

It does not appear that a fixed loaderdev
definition can even be used to pick out
the MMC (or any other specific device)
unless what else is connected is also
controlled (stable properties from boot
to boot).

In the above both disk0 and disk1 could
be bootable, each having a UFS partition
with /boot/ (including a kernel and dtb)
and /etc/ materials (including fstab).

So for what I was doing one way to be sure
of what boots is to plug-in just one USB
drive, the one to be booted from.

In that case, the usdcard (mmcsd0) does not
need a UFS partition, or if it has one, does
not need a /boot/ or /etc/ at all: it will
be ignored and the USB drive will be used
instead.

I removed /boot/ and /etc/ from the usdcard's
UFS partition and it still booted from the
"first" USB SSD stick [(0) above].

So a sufficient usdcard has a msdosfs
with:

# du -Asm /media/*
1       /media/BOOTCODE.BIN
1       /media/CONFIG.TXT
1       /media/FIXUP.DAT
1       /media/FIXUP_CD.DAT
1       /media/FIXUP_X.DAT
1       /media/LICENCE.broadcom
1       /media/README
3       /media/START.ELF
1       /media/START_CD.ELF
4       /media/START_X.ELF
1       /media/U-BOOT.BIN
1       /media/fixup_db.dat
5       /media/start_db.elf
1       /media/ubldr.bin

So. . .
Ports based:
sysutils/rpi-firmware content
sysutils/u-boot-rpi2 content

installworld copy based:
boot/ubldr.bin copy

One could define loaderdev in
CONFIG.TXT as I understand, but
its content could need to vary
when any drive connections
change, such as how many or
where various USB drives are
connected.

For reference for the example
at hand:

loader> lsdev
disk devices:
        disk0 (USB)
        disk0p1: FreeBSD UFS
        disk0p2: FreeBSD swap
        disk1 (USB)
        disk1p1: FreeBSD UFS
        disk1p2: FreeBSD swap
        disk1p3: DOS/Windows
        disk2 (MMC)
        disk2s1: DOS/Windows
        disk2s2: FreeBSD
net devices:
        net0:


loaderdev related source code details:

. . .
device_types[] =3D {
       { "disk", DEV_TYP_STOR },
       { "ide",  DEV_TYP_STOR | DT_STOR_IDE },
       { "mmc",  DEV_TYP_STOR | DT_STOR_MMC },
       { "sata", DEV_TYP_STOR | DT_STOR_SATA },
       { "scsi", DEV_TYP_STOR | DT_STOR_SCSI },
       { "usb",  DEV_TYP_STOR | DT_STOR_USB },
       { "net",  DEV_TYP_NET }
};
. . .
/*
* Parse a device string into type, unit, slice and partition numbers. A
* returned value of -1 for type indicates a search should be done for =
the
* first loadable device, otherwise a returned value of -1 for unit
* indicates a search should be done for the first loadable device of the
* given type.
*                             =20
* The returned values for slice and partition are interpreted by
* disk_open().        =20
*
* Valid device strings:                     For device types:
*
* <type_name>                               DEV_TYP_STOR, DEV_TYP_NET
* <type_name><unit>                         DEV_TYP_STOR, DEV_TYP_NET
* <type_name><unit>:                        DEV_TYP_STOR, DEV_TYP_NET
* <type_name><unit>:<slice>                 DEV_TYP_STOR
* <type_name><unit>:<slice>.                DEV_TYP_STOR
* <type_name><unit>:<slice>.<partition>     DEV_TYP_STOR
*
* For valid type names, see the device_types array, above.
*             =20
* Slice numbers are 1-based.  0 is a wildcard.
*/                    =20
static void
get_load_device(int *type, int *unit, int *slice, int *partition)
{
       char *devstr;
       const char *p;
       char *endp;

       *type =3D -1;
       *unit =3D -1;
       *slice =3D 0;
       *partition =3D -1;

       devstr =3D ub_env_get("loaderdev");
       if (devstr =3D=3D NULL) {
               printf("U-Boot env: loaderdev not set, will probe all =
devices.\n");
               return;
       }
       printf("U-Boot env: loaderdev=3D'%s'\n", devstr);
. . .

For gpt partitioned USB drives and the like, it is
not obvious what is best to specify for <slice> in
loaderdev .

=3D=3D=3D
Mark Millard
markmi at dsl-only.net




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90C085CE-25D6-4490-8221-7C5C2988BDD5>