Date: Thu, 23 Apr 2020 12:32:37 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Booting from USB on RPI3 Message-ID: <66AB22DA-9128-4A8B-8DAB-F846653A410E@yahoo.com> In-Reply-To: <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com> References: <mailman.61.1587470402.80084.freebsd-arm@freebsd.org> <trinity-4938b1d4-f29f-4907-bedd-65be21112e48-1587489497227@3c-app-webde-bs65> <20200421181224.GC96994@www.zefox.net> <trinity-19081201-3024-4046-817a-48321c51a515-1587587309088@3c-app-webde-bap64> <20200423162124.GA3583@www.zefox.net> <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On Wed, Apr 22, 2020 at 10:28:29PM +0200, Georg Lindenberg wrote:
>>>=20
>>> Uboot will run bootcmd, unless you hit a key. Then it will enter the =
shell.
>>>=20
>>> You can track down bootcmd (env print bootcmd):
>>>=20
>>> bootcmd=3Ddistro_bootcmd
>>> distro_bootcmd=3Dfor target in ${boot_targets}; do run =
bootcmd_${target}
>>> boot_targets=3Dmmc0 mmc1 usb0 pxe dhcp
>>>=20
>>> So, in this loop, usb0 is in third place. :-/ mmc will boot first.
>>>=20
>>> U-Boot> env print bootcmd_usb0
>>> bootcmd_usb0=3Ddevnum=3D0; run usb_boot
>>>=20
>>=20
>> For some reason I can't use run usb_boot, it's necessary to use
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 8 USB =
Device(s) found
>> scanning usb for storage devices... 1 Storage Device(s) found
>> U-Boot> run bootcmd_usb0
>>=20
>> Device 0: Vendor: Initio Rev: 1.06 Prod: MHT2040AH =20
>> Type: Hard Disk
>> Capacity: 38154.3 MB =3D 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@7e300000.blk...
>> Scanning disk usb_mass_storage.lun0...
>=20
> I ignore the above and start below.
>=20
>> Found 6 disks
>> BootOrder not defined
>> ^^^^^^^^^^^^^^^^^^^^^ this is trouble if it includes microsd devices
>=20
> 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:
>=20
> Found 7 disks
> BootOrder not defined
>=20
> I expect that the RPi3 set things up so a microsd card
> "wins" when present, even without the u-boot BootOrder
> definition being present.
>=20
>> EFI boot manager: Cannot load any image
>> ^^^^^^^^^^^^^^^^^^^^^ more bad news
>=20
> EFI boot manager: Cannot load any image
>=20
> So the same as you get for your USB-only experiments.
>=20
>> 687984 bytes read in 402 ms (1.6 MiB/s)
>=20
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> ^^^^^^^^^^^^^^^^ not sure about this
>=20
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>=20
> So the same as you get for your USB-only experiments.
>=20
>> Next comes a couple screens of linefeeds, then:
>=20
> 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.
>=20
>> Consoles: EFI console =20
>>=20
>> Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk1p1:
>=20
> =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=
=1B =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B
>=20
> So that is from the microsd card in my context.
>=20
>> FreeBSD/arm64 EFI loader, Revision 1.1
>=20
>> (Thu Apr 16 06:59:37 UTC 2020 root@releng1.nyi.freebsd.org)
>=20
> I do not get the above line's content.
>=20
>> Command line arguments: loader.efi
>=20
>> Image base: 0x39e91000
>=20
> The detailed figures is different in my context.
> I'll not list it.
>=20
>> EFI version: 2.80
>> EFI Firmware: Das U-Boot (rev 8217.4096)
>> Console: comconsole (0)
>> Load Path: /efi\boot\bootaa64.efi
>=20
>> 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)/Us=
bClass(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)/Us=
bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
>=20
> I'll not show the long lines for the microsd card here.
>=20
>> Setting currdev to disk1p1:
>=20
> S=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B=
=1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B
>=20
> (So the microsd card device.)
>=20
>> 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)/Us=
bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39)
>> Setting currdev to disk1p2:
>=20
> (Another long line then:)
>=20
> =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=
=1B =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B:=1B
>=20
> 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).
>=20
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> Loading kernel...
>=20
>> /boot/kernel/kernel text=3D0x9b804c data=3D0x192958 data=3D0x0+0x3a21fe=
syms=3D[0x8+0x10f740+0x8+0x134f85]
>=20
> The detailed figures are different in my context.
> I'll not list them.
>=20
>> Loading configured modules...
>=20
>> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x1390 data=3D0x6e0+0x10 =
syms=3D[0x8+0xf48+0x8+0xb6e]
>=20
> The detailed figures are different in my context.
> I'll not list them.
>=20
>> can't find '/boot/entropy'
>=20
> I have a /boot/entropy file setup that is working
> so I got:
>=20
> /=1Bb=1Bo=1Bo=1Bt=1B/=1Be=1Bn=1Bt=1Br=1Bo=1Bp=1By=1B =
=1Bs=1Bi=1Bz=1Be=1B=3D=1B0=1Bx=1B1=1B0=1B0=1B0=1B
>=20
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>=20
>>=20
>> Type '?' for a list of commands, 'help' for more detailed help.
>>=20
>>=20
>> It's unclear where the kernel loaded from,
>=20
> 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.
>=20
>> but at this point a=20
>> 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?=20
>>=20
>> It looks as if loader is confused about what disk it's on:
>>=20
>> OK show rootdev
>> variable 'rootdev' not found
>> OK=20
>=20
> Type '?' for a list of commands, 'help' for more detailed help.
> OK show rootdev
> variable 'rootdev' not found
> OK=20
>=20
> So this appears to be normal for microsd card use
> as well.
>=20
>> Running show reports, among many other things:
>> currdev=3Ddisk1p2:
>> kernel=3Dkernel
>> kernel_options=3D
>> kernel_path=3D/boot/kernel
>> kernelname=3D/boot/kernel/kernel
>> kernels_autodetect=3DYES
>> loaddev=3Ddisk1p2:
>> ^ the colon looks a little odd
>=20
> currdev=3Ddisk0p2:
> kernel=3Dkernel
> kernel_options=3D
> kernel_path=3D/boot/kernel
> kernelname=3D/boot/kernel/kernel
> kernels_autodetect=3DYES
> loaddev=3Ddisk0p2:
>=20
> 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).
>=20
>> The loaddev would make sense if mmcsd is device 0, I'm not sure =
that's true.
>=20
> "disk0" is apparently reserved for the microsd card slot
> media, even when there is no media there.
>=20
> "disk1" for the USB disk (when there is only one).
>=20
> "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.
>=20
>> What's the simplest way to inform loader on the usb device it's =
actually
>> _on_ the usb device. I've tried setting rootdev=3Dda0s2a, didn't =
work.
>=20
> 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 =3D 0x0
global NV,BS,RS PlatformLang =3D en-US
global BS,RS PlatformLangCodes =3D en-US
global BS,RS RuntimeServicesSupported =3D=20
80 05=20
freebsd BS,RS LoaderDev =3D =
/VenHw(LONG-ID-REMOVED)/SD(0)/SD(0)/HD(1,0x01,0,0x403b,0x1ffe0)
freebsd BS,RS LoaderPath =3D /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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66AB22DA-9128-4A8B-8DAB-F846653A410E>