Booting from USB on RPI3

Thu Apr 23 19:32:46 UTC 2020

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

> On 2020-Apr-23, at 09:21, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote:
>>> 
>>> Uboot will run bootcmd, unless you hit a key. Then it will enter the shell.
>>> 
>>> You can track down bootcmd (env print bootcmd):
>>> 
>>> bootcmd=distro_bootcmd
>>> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}
>>> boot_targets=mmc0 mmc1 usb0 pxe dhcp
>>> 
>>> So, in this loop, usb0 is in third place. :-/ mmc will boot first.
>>> 
>>> U-Boot> env print bootcmd_usb0
>>> bootcmd_usb0=devnum=0; run usb_boot
>>> 
>> 
>> For some reason I can't use run usb_boot, it's necessary to use
>> U-Boot>  usb reset
>> resetting USB...
>> Bus usb at 7e980000: scanning bus usb at 7e980000 for devices... 8 USB Device(s) found
>>      scanning usb for storage devices... 1 Storage Device(s) found
>> U-Boot> run bootcmd_usb0
>> 
>> Device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH       
>>           Type: Hard Disk
>>           Capacity: 38154.3 MB = 37.2 GB (78140160 x 512)
>> ... is now current device
>> Scanning usb 0:1...
>> Found EFI removable media binary efi/boot/bootaa64.efi
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> Scanning disk mmc at 7e300000.blk...
>> Scanning disk usb_mass_storage.lun0...
> 
> I ignore the above and start below.
> 
>> Found 6 disks
>> BootOrder not defined
>> ^^^^^^^^^^^^^^^^^^^^^ this is trouble if it includes microsd devices
> 
> My context has the msdosfs/EFI materials and FreeBSD loader.conf
> and kernel materials on the microsd card and a gpt partitioned USB
> SSD with the ufs file sytem on USB (loader.conf directs it there).
> I'll note things that you marked and how they look in my microsd
> card based. For the above:
> 
> Found 7 disks
> BootOrder not defined
> 
> I expect that the RPi3 set things up so a microsd card
> "wins" when present, even without the u-boot BootOrder
> definition being present.
> 
>> EFI boot manager: Cannot load any image
>>                 ^^^^^^^^^^^^^^^^^^^^^ more bad news
> 
> EFI boot manager: Cannot load any image
> 
> So the same as you get for your USB-only experiments.
> 
>> 687984 bytes read in 402 ms (1.6 MiB/s)
> 
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>                          ^^^^^^^^^^^^^^^^ not sure about this
> 
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> 
> So the same as you get for your USB-only experiments.
> 
>> Next comes a couple screens of linefeeds, then:
> 
> My binary capture of the serial stream shows
> escape sequences with [2J [2J and then lots of
> [?25h interlaced with what follows (for some
> distance). There are also sub-sequences of a
> repeating |/-\ sequence mixed in at various
> points. I'll omit such.
> 
>> Consoles: EFI console  
>> 
>>   Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk1p1:
> 
> Setting currdev to disk0p1:
> 
> So that is from the microsd card in my context.
> 
>> FreeBSD/arm64 EFI loader, Revision 1.1
> 
>> (Thu Apr 16 06:59:37 UTC 2020 root at releng1.nyi.freebsd.org)
> 
> I do not get the above line's content.
> 
>>  Command line arguments: loader.efi
> 
>>  Image base: 0x39e91000
> 
> The detailed figures is different in my context.
> I'll not list it.
> 
>>  EFI version: 2.80
>>  EFI Firmware: Das U-Boot (rev 8217.4096)
>>  Console: comconsole (0)
>>  Load Path: /efi\boot\bootaa64.efi
> 
>>  Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
>> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> 
> I'll not show the long lines for the microsd card here.
> 
>> Setting currdev to disk1p1:
> 
> Setting currdev to disk0p1:
> 
> (So the microsd card device.)
> 
>> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39)
>> Setting currdev to disk1p2:
> 
> (Another long line then:)
> 
> Setting currdev to disk0p2:
> 
> There are no long lines or references to the
> USB SSD that is present in my context: no
> examples if disk1p*: matches. Probably because
> of the gpt partitioning on that drive (and
> lack of any msdos like file systems).
> 
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> Loading kernel...
> 
>> /boot/kernel/kernel text=0x9b804c data=0x192958 data=0x0+0x3a21fe syms=[0x8+0x10f740+0x8+0x134f85]
> 
> The detailed figures are different in my context.
> I'll not list them.
> 
>> Loading configured modules...
> 
>> /boot/kernel/umodem.ko text=0x2100 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e]
> 
> The detailed figures are different in my context.
> I'll not list them.
> 
>> can't find '/boot/entropy'
> 
> I have a /boot/entropy file setup that is working
> so I got:
> 
> /boot/entropy size=0x1000
> 
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> 
>> 
>> Type '?' for a list of commands, 'help' for more detailed help.
>> 
>> 
>> It's unclear where the kernel loaded from,
> 
> Given the lack of references to any disk0p*: in your
> sequence, yours came from the USB drive. And if there
> is only one kernel instance there, it came from that
> copy.
> 
>> but at this point a 
>> listing of /boot reports the files on the USB disk, not microSD.
>> The image is from a 12.1 snapshot. /firstboot has been renamed
>> no.firstboot, might that be significant? 
>> 
>> It looks as if loader is confused about what disk it's on:
>> 
>> OK show rootdev
>> variable 'rootdev' not found
>> OK 
> 
> Type '?' for a list of commands, 'help' for more detailed help.
> OK show rootdev
> variable 'rootdev' not found
> OK 
> 
> So this appears to be normal for microsd card use
> as well.
> 
>> Running show reports, among many other things:
>> currdev=disk1p2:
>> kernel=kernel
>> kernel_options=
>> kernel_path=/boot/kernel
>> kernelname=/boot/kernel/kernel
>> kernels_autodetect=YES
>> loaddev=disk1p2:
>>              ^ the colon looks a little odd
> 
> currdev=disk0p2:
> kernel=kernel
> kernel_options=
> kernel_path=/boot/kernel
> kernelname=/boot/kernel/kernel
> kernels_autodetect=YES
> loaddev=disk0p2:
> 
> So this appears to be normal for microsd card use
> and your is analogous for USB drive use (when there
> is only one USB drive present).
> 
>> The loaddev would make sense if mmcsd is device 0, I'm not sure that's true.
> 
> "disk0" is apparently reserved for the microsd card slot
> media, even when there is no media there.
> 
> "disk1" for the USB disk (when there is only one).
> 
> "disk1", "disk2", . . . when there are multiple USB disks.
> The binding of each to which disk might not be stable or
> might track which USB connection point was used or some
> such. I've not tested.
> 
>> What's the simplest way to inform loader on the usb device it's actually
>> _on_ the usb device. I've tried setting rootdev=da0s2a, didn't work.
> 
> da0s2a is FreeBSD notation. This appears to be too early
> for that and is using a different "name space" that has
> "diskNpM:" notation. Your disk0p2: is what turns into
> da0s2 or da0s2a in FreeBSD. This is another stage where
> having multiple USB drives might not have a stable
> binding to daN naming. such is one of the reasons that
> using labeling for identification is recommended:
> Identification my referencing unique content set up
> for the purpose.

I should have also shown two more commands
with output for my context:

OK lsdev
disk devices:
    disk0:    249737217 X 512 blocks (removable)
      disk0s1: DOS/Windows
      disk0s2: FreeBSD
        disk0s2a: FreeBSD UFS
    disk1:    468862129 X 512 blocks
      disk1p1: FreeBSD UFS
      disk1p2: FreeBSD swap
      disk1p4: FreeBSD swap

So the above shows the loader's notation. But,
if there are multiple drives with the same size
and partition/slice types and sizes, figuring
out what is which is which could be a problem.

The lack of a disk1p3: is from historical
gpt partition editing, including delation
in the history for the USB SSD drive.

OK efi-show
global BS,RS OsIndicationsSupported = 0x0
global NV,BS,RS PlatformLang = en-US
global BS,RS PlatformLangCodes = en-US
global BS,RS RuntimeServicesSupported = 
80 05 
freebsd BS,RS LoaderDev = /VenHw(LONG-ID-REMOVED)/SD(0)/SD(0)/HD(1,0x01,0,0x403b,0x1ffe0)
freebsd BS,RS LoaderPath = /efi\boot\bootaa64.efi

Note: "LONG-ID-REMOVED" is not the original output text.

So the 2 "freebsd" lines show where bootaa64.efi
(the loader) is from, but in an even earlier namespace
for such identification.

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