Date: Fri, 12 Jun 2020 19:36:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: myfreeweb <greg@unrelenting.technology> Cc: Robert Crowston <crowston@protonmail.com>, =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Unrelenting testplan D25219 [successful boot with other details] Message-ID: <DF10A2AD-21A5-4934-8E4E-B9FC5D8B7CB0@yahoo.com> In-Reply-To: <8E5794F2-EB53-465B-ADB6-D9896FACDD78@unrelenting.technology> References: <876E685B-B3AC-4821-A88F-702ABA3D9812@yahoo.com> <5FE76178-4255-46B0-9A0D-F7640EFCBBE4@googlemail.com> <F1DC2AFB-0CC7-407D-A6C0-4E109590612E@unrelenting.technology> <C7D9957A-5C58-48FF-9601-7DD13DE9D89B@googlemail.com> <8414e0163e5cb2e9c4a4c7b02aa01666@unrelenting.technology> <5B8A58D0-9662-49DD-9CC3-226A3A92EFD6@googlemail.com> <abc05bea-ea4a-9189-611c-a1a0000182d8@selasky.org> <FE0813DD-29CA-4ADA-BD6B-963E3DC635B2@googlemail.com> <eHCAzXv-Rr39w3F-euypm4DrLx9jd88297x9hyHaNi_-VXR-ZiLdgFg6HvpI87aFLHGM_YcbOLADi0BLIR0jy557fbWDxKs4yIqf5ZfsDZ4=@protonmail.com> <097cbf6a-7b47-9346-c3af-fee7e709e1fa@selasky.org> <c153681ede0b1aeea61ea75405bc2fa9e844979e.camel@freebsd.org> <8E5794F2-EB53-465B-ADB6-D9896FACDD78@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jun-12, at 11:17, myfreeweb <greg at unrelenting.technology> =
wrote:
>> . . .
>=20
>=20
> That is what I did in D25219. Works for me.
>=20
> (Again, the firmware has a memory limiter option that makes it easy to =
check whether DMA location is the problem)
Here is what happened when I tried using
D25201.diff , D25203.diff , and D25219.diff
with just UEFI v1.14 materials on the microsd
card for a 4 GiByte RPi4, USB3 SSD for the
FreeBSD file system and the loader's msdosfs
. . .
This was based on a head -r360311 context that
is structured to allowing booting either a Rock64
or a RPi4 from the same USB3 SSD.
Note:
The loader.efi ( as EFI\BOOT\BOOTAA64.EFI in the
USB SSD's msdosfs) is from a much more recent
system build than -r360311 in order to not hit
an error that prevents the loader's operation in
this UEFI context. ( I extracted the loader.efi
from an artifacts.ci base.txz .)
On the Rock64:
A) Applied D25201.diff , D25203.diff , D25219.diff .
B) Did a buildkernel .
C) Did an installkernel .
D) Rebooted to check basic operation of the Rock64.
E) shutdown -p now .
F) Unplugged the USB3 SSD that holds the root file
system.
On the 4 GiByte RPi4 (that had the UEFI/ACPI microsd
card in place):
G) Plugged in that same USB3 SSD.
H) Powered on.
It booted but does not have any /dev/mmcsd0*=20
and ifconfig only shows lo0 (no Ethernet).
(I'd not prepared /etc/fstab for the lack of
/dev/label/*'s that would normally be from
/dev/mmcsd0*'s . So there were consequences
to not finding everything but they are not
important here and later reboots had
/etc/fstab set up to match the context.)
For each boot, I did get one "xhci0: Resetting
controller" and some other possibly related
messages as it was dealing with USB related
discovery. The first power-on example of
this looked like:
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights =
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r360311M: Fri Jun 12 16:48:22 PDT 2020
=
root@Rock64orRPi4:/usr/obj/cortexA53_clang_via_poud/arm64.aarch64/usr/src/=
arm64.aarch64/sys/GENERIC-NODBG arm64
FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-10.0.0-0-gd32170dbd5b)
VT(efifb): resolution 1920x1080
module firmware already present!
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.
random: entropy device external interface
MAP 1d0000 mode 2 pages 32
MAP 33930000 mode 2 pages 80
MAP 33a10000 mode 2 pages 128
MAP 33ab0000 mode 2 pages 128
MAP 37000000 mode 2 pages 400
MAP 37190000 mode 2 pages 592
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD =
13.0.
kbd0 at kbdmux0
WARNING: Device "openfirm" is Giant locked and may be deleted before =
FreeBSD 13.0.
acpi0: <RPIFDN RPI4>
acpi0: Power Button (fixed)
acpi0: Could not update all GPEs: AE_NOT_CONFIGURED
psci0: <ARM Power State Co-ordination Interface Driver> on acpi0
gic0: <ARM Generic Interrupt Controller> iomem =
0xff841000-0xff841fff,0xff842000-0xff842fff on acpi0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
generic_timer0: <ARM Generic Timer> irq 15,16,17 on acpi0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 0.000001s
acpi_syscontainer0: <System Container> on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_syscontainer1: <System Container> on acpi0
xhci0: <Generic USB 3.0 controller> iomem 0x600000000-0x600000fff irq 0 =
on acpi0
xhci0: 32 bytes context size, 32-bit DMA
usbus0 on xhci0
dwcotg0: <DWC OTG 2.0 integrated USB controller> iomem =
0xfe980000-0xfe98ffff irq 1 on acpi0
usbus1 on dwcotg0
uart0: <PrimeCell UART (PL011)> iomem 0xfe201000-0xfe201fff irq 11 on =
acpi0
uart0: console (115200,n,8,1)
cryptosoft0: <software crypto>
Timecounters tick every 1.000 msec
Obsolete code will be removed soon: random(9) is the obsolete =
Park-Miller LCG from 1988
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
. . . (Skipping APs and mount root related text) . . .
ugen1.1: <DWCOTG OTG Root HUB> at usbus1
ugen0.1: <Generic XHCI root HUB> at usbus0
uhub0 on usbus1
uhub1 on usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
uhub1: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on =
usbus0
uhub0: 1 port with 1 removable, self powered
uhub1: 5 ports with 4 removable, self powered
Root mount waiting for: usbus0 CAM
xhci0: Resetting controller
usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored)
ugen0.2: <Unknown > at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
Root mount waiting for: usbus0 CAM
usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored)
ugen0.2: <Unknown > at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
uhub1: at usbus0, port 1, addr 1 (disconnected)
uhub1: detached
uhub1 on usbus0
uhub1: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on =
usbus0
uhub1: 5 ports with 4 removable, self powered
Root mount waiting for: CAM
ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0
uhub2 on uhub1
uhub2: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.20, addr 1> on =
usbus0
uhub2: 4 ports with 4 removable, self powered
Root mount waiting for: CAM
Root mount waiting for: CAM
ugen0.3: <OWC Envoy Pro mini> at usbus0
umass0 on uhub1
umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 2> on usbus0
umass0: SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number #...#
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>
. . .
FYI, I did not have UEFI limit RAM use to 3 GiBytes:
# vmstat=20
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us =
sy id
0 0 0 52M 3.7G 6 0 0 0 11 0 0 0 54 7 323 0 =
0 100
I had picked the Serial style of console in the UEFI
configuration, not Graphical.
I had the RPi4 config.txt using dtoverlay=3Ddisable-bt
and, so, use the PL011 for the serial console. (So I
also had the overlay present for doing the disable.)
I had controlled the UEFI's boot order list: first the
USB3 SSD then the microsd then the UEFI Shell then the
PXEv* and HTTPv* alternatives (unused). (UEFI Shell
shows up despite not being listed in the Change Boot
Order list.)
So for the RPi4 finding the root file system . . .
Consoles: serial port =20
Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk1p3:
FreeBSD/arm64 EFI loader, Revision 1.1
(Wed Jun 10 20:35:29 UTC 2020 =
root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org)
Command line arguments: loader.efi
Image base: 0x33830000
EFI version: 2.70
EFI Firmware: https://github.com/pftf/RPi4 (rev 1.00)
Console: comconsole (0)
Load Path: \EFI\BOOT\BOOTAA64.EFI
Load Device: =
PcieRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)/HD(3,GPT,#...#,0x1930=
0800,0x32000)
BootCurrent: 0003
BootOrder: 0003[*] 0002 0000 0001
BootInfo Path: PcieRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)
Ignoring Boot0003: Only one DP found
Trying ESP: =
PcieRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)/HD(3,GPT,3#...#,0x193=
00800,0x32000)
Setting currdev to disk1p3:
Trying: =
PcieRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/USB(0x1,0x0)/HD(1,GPT,#...#,0x800,=
0x18A00000)
Setting currdev to disk1p1:
. . .
I had CPU Clock Default in UEFI with the RPi config.txt
indicating over_voltage=3D6 and arm_freq=3D2000 . It was used
by FreeBSD:
# openssl speed md5
Doing md5 for 3s on 16 size blocks: 11037504 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 6521461 md5's in 3.02s
Doing md5 for 3s on 256 size blocks: 2928275 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 914698 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 123256 md5's in 3.00s
Doing md5 for 3s on 16384 size blocks: 61977 md5's in 3.00s
OpenSSL 1.1.1g-freebsd 21 Apr 2020
built on: reproducible build, date unspecified
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)=20=
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 =
bytes 16384 bytes
md5 58866.69k 138403.65k 249879.47k 312216.92k =
336571.05k 338477.06k
Compare that to booting via the sysutils/u-boot-rpi4 materials
(separate microsd card, not using the USB3 SSD):
# openssl speed md5
Doing md5 for 3s on 16 size blocks: 3621495 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 2201105 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 990468 md5's in 3.02s
Doing md5 for 3s on 1024 size blocks: 306651 md5's in 3.02s
Doing md5 for 3s on 8192 size blocks: 41305 md5's in 3.02s
Doing md5 for 3s on 16384 size blocks: 20807 md5's in 3.03s
OpenSSL 1.1.1g-freebsd 21 Apr 2020
built on: reproducible build, date unspecified
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)=20=
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 =
bytes 16384 bytes
md5 19314.64k 46956.91k 84082.01k 104127.88k =
111915.84k 112462.48k
"shutdown -r now" seems to work fine for the
UEFI/ACPI context.
I hope that the above notes help.
=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?DF10A2AD-21A5-4934-8E4E-B9FC5D8B7CB0>