Date: Thu, 23 Apr 2020 12:14:57 -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: <9C2E0F98-AF80-4105-B109-B4767AE53FFF@yahoo.com> In-Reply-To: <20200423162124.GA3583@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=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...
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 =20
>=20
> Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk1p1:
=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
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@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)/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)
I'll not show the long lines for the microsd card here.
> Setting currdev to disk1p1:
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
(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)/Us=
bClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39)
> Setting currdev to disk1p2:
(Another long line then:)
=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
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=3D0x9b804c data=3D0x192958 data=3D0x0+0x3a21fe =
syms=3D[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=3D0x2100 text=3D0x1390 data=3D0x6e0+0x10 =
syms=3D[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:
/=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
> 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,
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=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
Type '?' for a list of commands, 'help' for more detailed help.
OK show rootdev
variable 'rootdev' not found
OK=20
So this appears to be normal for microsd card use
as well.
> 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
currdev=3Ddisk0p2:
kernel=3Dkernel
kernel_options=3D
kernel_path=3D/boot/kernel
kernelname=3D/boot/kernel/kernel
kernels_autodetect=3DYES
loaddev=3Ddisk0p2:
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=3Dda0s2a, 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.
=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?9C2E0F98-AF80-4105-B109-B4767AE53FFF>