Discussion:
/usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)"
Mark Millard via freebsd-arm
2021-05-13 08:52:08 UTC
Permalink
The updated armv7 U-Boot ports now install the likes of:

# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin

# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin

So, for example, no boot.scr files ro go with ubldr.bin
any more.

But the u-boot-orangepi-plus-2e/README says . . .

QUOTE
This version is patched so that:
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE

The u-boot-rpi2/README says . . .

QUOTE
This version is patched so that:
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE


But for the orangepi-plus-2e that I have access to I
now get:

. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)

and that is the last of the output.

The RPi2 v1.1 is similar:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)

and that is the last of the output.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Emmanuel Vadot
2021-05-13 09:15:17 UTC
Permalink
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
--
Emmanuel Vadot <***@bidouilliste.com> <***@freebsd.org>
Mark Millard via freebsd-arm
2021-05-13 09:57:21 UTC
Permalink
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
using ". . ." for other omitted text):

U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)

and:

U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)

No *.scr files, no ubldr* files. Showing
from the efi partition mounted on a Rock64:

# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo

# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi

# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin

# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument

I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Emmanuel Vadot
2021-05-13 10:40:50 UTC
Permalink
On Thu, 13 May 2021 02:57:21 -0700
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
I cannot reproduce this here. Either by creating an image on the
sdcard by hand (I usually only netboot my boards so the sdcard have
only u-boot and a fat partition so u-boot can save its env) or by
taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding
u-boot on it.
This was tested on an orangepi-one board (so same SoC, Allwinner H3)
and on a BeagleBoneBlack.
I suggest to try with a clean install from
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure.
Post by Mark Millard via freebsd-arm
U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
This line doesn't looks good.
Post by Mark Millard via freebsd-arm
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
No *.scr files, no ubldr* files. Showing
# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo
# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi
# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin
# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument
I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
--
Emmanuel Vadot <***@bidouilliste.com> <***@freebsd.org>
Mark Millard via freebsd-arm
2021-05-13 11:08:51 UTC
Permalink
Post by Emmanuel Vadot
On Thu, 13 May 2021 02:57:21 -0700
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
I cannot reproduce this here. Either by creating an image on the
sdcard by hand (I usually only netboot my boards so the sdcard have
only u-boot and a fat partition so u-boot can save its env) or by
taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding
u-boot on it.
This was tested on an orangepi-one board (so same SoC, Allwinner H3)
and on a BeagleBoneBlack.
I suggest to try with a clean install from
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure.
In my context:

The RPi2 v1.1 has a microsd card with just bootcode.bin .
The rest is from the USB3 SSD media. (Such worked before
the U-Boot update, for example.)

The orangepi-plus-2e has a microsd card with just its
(now updated) U-Boot and empty file systems. The rest
is from the USB3 SSD media.

It is the same USB3 SSD boot media used for both.

It is the same media I've been using right along,
just updated to remove the old U-Boot related
extra materials and to copy over the new U-Boot
for the RPi2 V1.1.

The media has a non-debug head [so: 14] build, based
on:

merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

It has been working the whole time since then until
this change. It is a build with code generation
tuned for cortex-A7, as is my normal for my own
builds for armv7.

I need to get some sleep. So it will be some time
before I try any other forms of experiments.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
This line doesn't looks good.
Yea, I noticed it but have done no investigation
as yet. (Only the RPi2 v1.1 that message. It is
the one notable difference.)
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
No *.scr files, no ubldr* files. Showing
# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo
# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi
# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin
# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument
I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via freebsd-arm
2021-05-13 17:53:22 UTC
Permalink
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 02:57:21 -0700
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
I cannot reproduce this here. Either by creating an image on the
sdcard by hand (I usually only netboot my boards so the sdcard have
only u-boot and a fat partition so u-boot can save its env) or by
taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding
u-boot on it.
This was tested on an orangepi-one board (so same SoC, Allwinner H3)
and on a BeagleBoneBlack.
I suggest to try with a clean install from
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure.
The RPi2 v1.1 has a microsd card with just bootcode.bin .
The rest is from the USB3 SSD media. (Such worked before
the U-Boot update, for example.)
The orangepi-plus-2e has a microsd card with just its
(now updated) U-Boot and empty file systems. The rest
is from the USB3 SSD media.
It is the same USB3 SSD boot media used for both.
It is the same media I've been using right along,
just updated to remove the old U-Boot related
extra materials and to copy over the new U-Boot
for the RPi2 V1.1.
The media has a non-debug head [so: 14] build, based
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
It has been working the whole time since then until
this change. It is a build with code generation
tuned for cortex-A7, as is my normal for my own
builds for armv7.
I need to get some sleep. So it will be some time
before I try any other forms of experiments.
Mixed results for starting with a modified
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img microsd
card:

orangepi-plus-2e booted from the microsd card.

rpi2 v1.1 failed the same way as before, including:

Found EFI removable media binary efi/boot/bootarm.efi
1403700 bytes read in 139 ms (9.6 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootarm.efi
Consoles: EFI console

FYI, FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img includes
ubldr.bin :

# ls -Tld /mnt/*
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:26 2021 /mnt/EFI
-rwxr-xr-x 1 root wheel 103488 Apr 8 20:59:46 2021 /mnt/MLO
-rwxr-xr-x 1 root wheel 26745 Mar 3 05:29:56 2021 /mnt/bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root wheel 52456 Mar 3 05:29:56 2021 /mnt/bootcode.bin
-rwxr-xr-x 1 root wheel 89 Apr 8 21:10:14 2021 /mnt/config.txt
drwxr-xr-x 1 root wheel 8192 Apr 9 00:05:26 2021 /mnt/dtb
-rwxr-xr-x 1 root wheel 7314 Mar 3 05:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x 1 root wheel 3187 Mar 3 05:29:56 2021 /mnt/fixup_cd.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_db.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:32 2021 /mnt/overlays
-rwxr-xr-x 1 root wheel 2952960 Mar 3 05:29:56 2021 /mnt/start.elf
-rwxr-xr-x 1 root wheel 793116 Mar 3 05:29:56 2021 /mnt/start_cd.elf
-rwxr-xr-x 1 root wheel 4794472 Mar 3 05:29:56 2021 /mnt/start_db.elf
-rwxr-xr-x 1 root wheel 3704808 Mar 3 05:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x 1 root wheel 467824 Apr 8 21:09:28 2021 /mnt/u-boot.bin
-rwxr-xr-x 1 root wheel 716804 Apr 8 20:59:46 2021 /mnt/u-boot.img
-r-xr-xr-x 1 root wheel 462412 Apr 9 00:00:00 2021 /mnt/ubldr.bin

so I removed that and u-boot.img, and replaced u-boot.bin .
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
This line doesn't looks good.
Yea, I noticed it but have done no investigation
as yet. (Only the RPi2 v1.1 that message. It is
the one notable difference.)
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
No *.scr files, no ubldr* files. Showing
# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo
# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi
# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin
# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument
I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via freebsd-arm
2021-05-13 19:03:12 UTC
Permalink
Post by Mark Millard via freebsd-arm
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 02:57:21 -0700
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
I cannot reproduce this here. Either by creating an image on the
sdcard by hand (I usually only netboot my boards so the sdcard have
only u-boot and a fat partition so u-boot can save its env) or by
taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding
u-boot on it.
This was tested on an orangepi-one board (so same SoC, Allwinner H3)
and on a BeagleBoneBlack.
I suggest to try with a clean install from
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure.
The RPi2 v1.1 has a microsd card with just bootcode.bin .
The rest is from the USB3 SSD media. (Such worked before
the U-Boot update, for example.)
The orangepi-plus-2e has a microsd card with just its
(now updated) U-Boot and empty file systems. The rest
is from the USB3 SSD media.
It is the same USB3 SSD boot media used for both.
It is the same media I've been using right along,
just updated to remove the old U-Boot related
extra materials and to copy over the new U-Boot
for the RPi2 V1.1.
The media has a non-debug head [so: 14] build, based
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
It has been working the whole time since then until
this change. It is a build with code generation
tuned for cortex-A7, as is my normal for my own
builds for armv7.
I need to get some sleep. So it will be some time
before I try any other forms of experiments.
Mixed results for starting with a modified
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img microsd
orangepi-plus-2e booted from the microsd card.
I took the microsd card and put it in a USB media
reader and plugged it into the USB port and used the
microsd card with only U-Boot on it in the microsd
card slot. So, in essence, a test of USB booting
from as close to the same media content as I can
get.

It failed in the same way as I previously reported
for the orangepi-plus-2e (which was also a form of
USB booting --but with my historical USB SSD media
that has a main [so: 14] non-debug build).

The only software that I had built was the U-Boots
themselves that I either dd'd or cp'd as appropriate.
EFI/BOOT/* was unchanged, as was FreeBSD's kernel
and world.

Somehow the type of the device matters (despite the
kernel being loaded from the device without
complaints). Apparently the RPi2 v1.1 microsd card
is a problematical type of device, like USB is for
the orangepi-plus-2e. A definite regression overall.
Post by Mark Millard via freebsd-arm
Found EFI removable media binary efi/boot/bootarm.efi
1403700 bytes read in 139 ms (9.6 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootarm.efi
Consoles: EFI console
FYI, FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img includes
# ls -Tld /mnt/*
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:26 2021 /mnt/EFI
-rwxr-xr-x 1 root wheel 103488 Apr 8 20:59:46 2021 /mnt/MLO
-rwxr-xr-x 1 root wheel 26745 Mar 3 05:29:56 2021 /mnt/bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root wheel 52456 Mar 3 05:29:56 2021 /mnt/bootcode.bin
-rwxr-xr-x 1 root wheel 89 Apr 8 21:10:14 2021 /mnt/config.txt
drwxr-xr-x 1 root wheel 8192 Apr 9 00:05:26 2021 /mnt/dtb
-rwxr-xr-x 1 root wheel 7314 Mar 3 05:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x 1 root wheel 3187 Mar 3 05:29:56 2021 /mnt/fixup_cd.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_db.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:32 2021 /mnt/overlays
-rwxr-xr-x 1 root wheel 2952960 Mar 3 05:29:56 2021 /mnt/start.elf
-rwxr-xr-x 1 root wheel 793116 Mar 3 05:29:56 2021 /mnt/start_cd.elf
-rwxr-xr-x 1 root wheel 4794472 Mar 3 05:29:56 2021 /mnt/start_db.elf
-rwxr-xr-x 1 root wheel 3704808 Mar 3 05:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x 1 root wheel 467824 Apr 8 21:09:28 2021 /mnt/u-boot.bin
-rwxr-xr-x 1 root wheel 716804 Apr 8 20:59:46 2021 /mnt/u-boot.img
-r-xr-xr-x 1 root wheel 462412 Apr 9 00:00:00 2021 /mnt/ubldr.bin
so I removed that and u-boot.img, and replaced u-boot.bin .
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
This line doesn't looks good.
Yea, I noticed it but have done no investigation
as yet. (Only the RPi2 v1.1 that message. It is
the one notable difference.)
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
No *.scr files, no ubldr* files. Showing
# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo
# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi
# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin
# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument
I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via arm
2021-05-24 22:53:17 UTC
Permalink
Post by Mark Millard via freebsd-arm
Post by Mark Millard via freebsd-arm
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 02:57:21 -0700
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
On Thu, 13 May 2021 01:52:08 -0700
Post by Mark Millard via freebsd-arm
# ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin
# ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/*
-rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/README
-rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/metadata
-rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin
So, for example, no boot.scr files ro go with ubldr.bin
any more.
But the u-boot-orangepi-plus-2e/README says . . .
QUOTE
* API features are enabled.
* A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included
END QUOTE
The u-boot-rpi2/README says . . .
QUOTE
* ELF and API features are enabled.
* The distroboot command knows how to load FreeBSD loader(8)
* By default, it loads ubldr.bin (PIE) from file ubldr.bin on the FAT
partition to address ${kernel_addr_r}, and launches it. If ubldr.bin is
not found, it falls back on ubldr
END QUOTE
Oups, I'll update the README, thanks for noticing this.
FYI: I only looked at examples for which I've access
to operational hardware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
But for the orangepi-plus-2e that I have access to I
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
This is the symptoms when caches are not flushed.
U-Boot distroboot first scans for extlinux.conf, then uboot script and
then EFI. So this probably means that you still have a boot.scr on the
ESP, try removing that and make sure that you have the efi loader too
in efi/boot/bootarm.efi.
That is not the issue . . . showing more context
from the same recorded boot attempts (blank lines
and a huge number of escape sequences removed, and
U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0xb8dd5000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 36 ms (37 MiB/s)
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
I cannot reproduce this here. Either by creating an image on the
sdcard by hand (I usually only netboot my boards so the sdcard have
only u-boot and a fat partition so u-boot can save its env) or by
taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding
u-boot on it.
This was tested on an orangepi-one board (so same SoC, Allwinner H3)
and on a BeagleBoneBlack.
I suggest to try with a clean install from
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure.
The RPi2 v1.1 has a microsd card with just bootcode.bin .
The rest is from the USB3 SSD media. (Such worked before
the U-Boot update, for example.)
The orangepi-plus-2e has a microsd card with just its
(now updated) U-Boot and empty file systems. The rest
is from the USB3 SSD media.
It is the same USB3 SSD boot media used for both.
It is the same media I've been using right along,
just updated to remove the old U-Boot related
extra materials and to copy over the new U-Boot
for the RPi2 V1.1.
The media has a non-debug head [so: 14] build, based
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
It has been working the whole time since then until
this change. It is a build with code generation
tuned for cortex-A7, as is my normal for my own
builds for armv7.
I need to get some sleep. So it will be some time
before I try any other forms of experiments.
Mixed results for starting with a modified
FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img microsd
orangepi-plus-2e booted from the microsd card.
I took the microsd card and put it in a USB media
reader and plugged it into the USB port and used the
microsd card with only U-Boot on it in the microsd
card slot. So, in essence, a test of USB booting
from as close to the same media content as I can
get.
It failed in the same way as I previously reported
for the orangepi-plus-2e (which was also a form of
USB booting --but with my historical USB SSD media
that has a main [so: 14] non-debug build).
The only software that I had built was the U-Boots
themselves that I either dd'd or cp'd as appropriate.
EFI/BOOT/* was unchanged, as was FreeBSD's kernel
and world.
Somehow the type of the device matters (despite the
kernel being loaded from the device without
complaints). Apparently the RPi2 v1.1 microsd card
is a problematical type of device, like USB is for
the orangepi-plus-2e. A definite regression overall.
Post by Mark Millard via freebsd-arm
Found EFI removable media binary efi/boot/bootarm.efi
1403700 bytes read in 139 ms (9.6 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootarm.efi
Consoles: EFI console
FYI, FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img includes
# ls -Tld /mnt/*
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:26 2021 /mnt/EFI
-rwxr-xr-x 1 root wheel 103488 Apr 8 20:59:46 2021 /mnt/MLO
-rwxr-xr-x 1 root wheel 26745 Mar 3 05:29:56 2021 /mnt/bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root wheel 52456 Mar 3 05:29:56 2021 /mnt/bootcode.bin
-rwxr-xr-x 1 root wheel 89 Apr 8 21:10:14 2021 /mnt/config.txt
drwxr-xr-x 1 root wheel 8192 Apr 9 00:05:26 2021 /mnt/dtb
-rwxr-xr-x 1 root wheel 7314 Mar 3 05:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x 1 root wheel 3187 Mar 3 05:29:56 2021 /mnt/fixup_cd.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_db.dat
-rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:32 2021 /mnt/overlays
-rwxr-xr-x 1 root wheel 2952960 Mar 3 05:29:56 2021 /mnt/start.elf
-rwxr-xr-x 1 root wheel 793116 Mar 3 05:29:56 2021 /mnt/start_cd.elf
-rwxr-xr-x 1 root wheel 4794472 Mar 3 05:29:56 2021 /mnt/start_db.elf
-rwxr-xr-x 1 root wheel 3704808 Mar 3 05:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x 1 root wheel 467824 Apr 8 21:09:28 2021 /mnt/u-boot.bin
-rwxr-xr-x 1 root wheel 716804 Apr 8 20:59:46 2021 /mnt/u-boot.img
-r-xr-xr-x 1 root wheel 462412 Apr 9 00:00:00 2021 /mnt/ubldr.bin
so I removed that and u-boot.img, and replaced u-boot.bin .
Post by Mark Millard via freebsd-arm
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
. . .
FreeBSD/arm EFI loader, Revision 1.1
Command line arguments: l
Image base: 0x39df8000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8225.1024)
Console: comconsole (0)
Load Path: /efi\boot\bootarm.efi
. . .
Found EFI removable media binary efi/boot/bootarm.efi
1396100 bytes read in 38 ms (35 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
This line doesn't looks good.
Yea, I noticed it but have done no investigation
as yet. (Only the RPi2 v1.1 that message. It is
the one notable difference.)
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/ Reading loader env vars from /efi/freebsd/loader.env
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
No *.scr files, no ubldr* files. Showing
# find /mnt/dtb/ -print
/mnt/dtb/
/mnt/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/dtb/overlays
/mnt/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/dtb/overlays/spigen-rpi2.dtbo
# find /mnt/efi/ -print
/mnt/efi/
/mnt/efi/boot
/mnt/efi/boot/bootarm.efi
# ls -Tld /mnt/u*
-rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 /mnt/u-boot.bin
# ls -Tld /mnt/*.scr
ls: /mnt/*.scr: Invalid argument
I'll not list the files from the RPi* firmware.
Post by Emmanuel Vadot
Post by Mark Millard via freebsd-arm
and that is the last of the output.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33e00200...
Kernel args: (null)
and that is the last of the output.
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.

But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)

After booting with the reverted U-Boot related
material:

# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media

# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..

# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin

The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).

If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).

For reference:

# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via arm
2021-05-25 03:10:50 UTC
Permalink
Post by Mark Millard via arm
. . .
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.
But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)
After booting with the reverted U-Boot related
# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media
# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin
The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).
If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
Looks like 2021.04 (even before 2021.04_1) also has the
problem for root-on-USB handling.

I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e
directory copy that was 2021.04 (and its boot.scr) but
before the UEFI change. When I tried it for the
root-on-USB context I still got the hangup after "Kernel
args: (null)" in:

. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)


So it does not appear to be the UEFI change so much as
2021.04 in general for which the FreeBSD kernel and
the U-Boot are apparently(?) mismatched for root-on-USB.


Reverting again to 2020.10 U-Boot got back the root-on-USB
status. For this the boot looks like:

. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47ef5000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm
FreeBSD clang version 11.0.1 (***@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
. . .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via arm
2021-05-31 05:27:31 UTC
Permalink
Post by Mark Millard via arm
Post by Mark Millard via arm
. . .
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.
But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)
After booting with the reverted U-Boot related
# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media
# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin
The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).
If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
Looks like 2021.04 (even before 2021.04_1) also has the
problem for root-on-USB handling.
I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e
directory copy that was 2021.04 (and its boot.scr) but
before the UEFI change. When I tried it for the
root-on-USB context I still got the hangup after "Kernel
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
So it does not appear to be the UEFI change so much as
2021.04 in general for which the FreeBSD kernel and
the U-Boot are apparently(?) mismatched for root-on-USB.
Reverting again to 2020.10 U-Boot got back the root-on-USB
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47ef5000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm
. . .
Well, I got a surprise in exploring: removing boot.scr
and ubldr.bin did not prevent booting. (Noticed by the
accident of ending up with one of them missing that I
only later noticed.) So I recorded a boot and:

. . .
U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology

CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini
Type: Hard Disk
Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning usb 0:4...
30675 bytes read in 3 ms (9.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
. . .
Booting /efi\boot\bootarm.efi
Consoles: EFI console


|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env


Setting currdev to disk2p4:


|/-\|/FreeBSD/arm EFI loader, Revision 1.1
. . .

So I've likely been been booting via UEFI for
some time via 2020.10 (or even before?), just
without noticing at the time.

The other implication is likely that what disabled
root-on-USB for my context was not the boot.scr
removal material but some (possibly proper) subset
of other material changed (extracted from
ports' main 0d6e5081eb00 commit cgit display):

diff --git a/sysutils/u-boot-master/files/FreeBSD_Fragment b/sysutils/u-boot-master/files/FreeBSD_Fragment
index 630d295cc8f1..f3837a932e98 100644
--- a/sysutils/u-boot-master/files/FreeBSD_Fragment
+++ b/sysutils/u-boot-master/files/FreeBSD_Fragment
@@ -1,3 +1,2 @@
-CONFIG_API=y
CONFIG_ARMV7_NONSEC=n
-CONFIG_CMD_CACHE=y
+CONFIG_EFI_GRUB_ARM32_WORKAROUND=y

diff --git a/sysutils/u-boot-master/files/patch-api_api.c b/sysutils/u-boot-master/files/patch-api_api.c
deleted file mode 100644
index 5de1e5e653d9..000000000000
--- a/sysutils/u-boot-master/files/patch-api_api.c
+++ /dev/null
@@ -1,14 +0,0 @@
---- api/api.c.orig 2018-07-09 14:24:14 UTC
-+++ api/api.c
-@@ -289,6 +289,11 @@ static int API_dev_close(va_list ap)
- if (!err)
- di->state = DEV_STA_CLOSED;
-
-+ if (dcache_status())
-+ flush_dcache_all();
-+ if (icache_status())
-+ invalidate_icache_all();
-+
- return err;
- }
-

diff --git a/sysutils/u-boot-master/files/FreeBSD_Fragment b/sysutils/u-boot-master/files/FreeBSD_Fragment
index 630d295cc8f1..f3837a932e98 100644
--- a/sysutils/u-boot-master/files/FreeBSD_Fragment
+++ b/sysutils/u-boot-master/files/FreeBSD_Fragment
@@ -1,3 +1,2 @@
-CONFIG_API=y
CONFIG_ARMV7_NONSEC=n
-CONFIG_CMD_CACHE=y
+CONFIG_EFI_GRUB_ARM32_WORKAROUND=y

diff --git a/sysutils/u-boot-master/files/boot.cmd b/sysutils/u-boot-master/files/boot.cmd
deleted file mode 100644
index b3ce82975eb3..000000000000
--- a/sysutils/u-boot-master/files/boot.cmd
+++ /dev/null
@@ -1,2 +0,0 @@
-fatload ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ubldr.bin && go ${kernel_addr_r}
-echo "Cannot load ubldr.bin"

diff --git a/sysutils/u-boot-master/files/patch-api_api.c b/sysutils/u-boot-master/files/patch-api_api.c
deleted file mode 100644
index 5de1e5e653d9..000000000000
--- a/sysutils/u-boot-master/files/patch-api_api.c
+++ /dev/null
@@ -1,14 +0,0 @@
---- api/api.c.orig 2018-07-09 14:24:14 UTC
-+++ api/api.c
-@@ -289,6 +289,11 @@ static int API_dev_close(va_list ap)
- if (!err)
- di->state = DEV_STA_CLOSED;
-
-+ if (dcache_status())
-+ flush_dcache_all();
-+ if (icache_status())
-+ invalidate_icache_all();
-+
- return err;
- }
-

diff --git a/sysutils/u-boot-master/files/patch-api_api__storage.c b/sysutils/u-boot-master/files/patch-api_api__storage.c
deleted file mode 100644
index 2e5846fb9a5c..000000000000
--- a/sysutils/u-boot-master/files/patch-api_api__storage.c
+++ /dev/null
@@ -1,25 +0,0 @@
---- api/api_storage.c.orig 2019-07-08 19:23:28 UTC
-+++ api/api_storage.c
-@@ -69,13 +69,6 @@ void dev_stor_init(void)
- specs[ENUM_SATA].type = DEV_TYP_STOR | DT_STOR_SATA;
- specs[ENUM_SATA].name = "sata";
- #endif
--#if defined(CONFIG_SCSI)
-- specs[ENUM_SCSI].max_dev = CONFIG_SYS_SCSI_MAX_DEVICE;
-- specs[ENUM_SCSI].enum_started = 0;
-- specs[ENUM_SCSI].enum_ended = 0;
-- specs[ENUM_SCSI].type = DEV_TYP_STOR | DT_STOR_SCSI;
-- specs[ENUM_SCSI].name = "scsi";
--#endif
- #if defined(CONFIG_CMD_USB) && defined(CONFIG_USB_STORAGE)
- specs[ENUM_USB].max_dev = USB_MAX_STOR_DEV;
- specs[ENUM_USB].enum_started = 0;
-@@ -281,7 +274,7 @@ int dev_enum_storage(struct device_info *di)
- {
- int i;
-
-- /* check: ide, usb, scsi, mmc */
-+ /* check: ide, usb, mmc */
- for (i = ENUM_IDE; i < ENUM_MAX; i ++) {
- if (dev_enum_stor(i, di))
- return 1;

diff --git a/sysutils/u-boot-master/files/patch-cmd_boot.c b/sysutils/u-boot-master/files/patch-cmd_boot.c
deleted file mode 100644
index b0c520aeb2ed..000000000000
--- a/sysutils/u-boot-master/files/patch-cmd_boot.c
+++ /dev/null
@@ -1,13 +0,0 @@
---- cmd/boot.c.orig 2018-07-09 14:24:14 UTC
-+++ cmd/boot.c
-@@ -18,6 +18,10 @@ __attribute__((weak))
- unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
- char * const argv[])
- {
-+ if (dcache_status())
-+ flush_dcache_all();
-+ if (icache_status())
-+ invalidate_icache_all();
- return entry (argc, argv);
- }
-

diff --git a/sysutils/u-boot-master/files/patch-cmd_elf.c b/sysutils/u-boot-master/files/patch-cmd_elf.c
deleted file mode 100644
index a6cac78a0989..000000000000
--- a/sysutils/u-boot-master/files/patch-cmd_elf.c
+++ /dev/null
@@ -1,14 +0,0 @@
---- cmd/elf.c.orig 2018-07-09 14:24:14 UTC
-+++ cmd/elf.c
-@@ -153,6 +153,11 @@ static unsigned long do_bootelf_exec(ulong (*entry)(in
- {
- unsigned long ret;
-
-+ if (dcache_status())
-+ flush_dcache_all();
-+ if (icache_status())
-+ invalidate_icache_all();
-+
- /*
- * pass address parameter as argv[0] (aka command name),
- * and all remaining args


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Mark Millard via arm
2021-05-31 05:32:38 UTC
Permalink
Post by Mark Millard via arm
Post by Mark Millard via arm
Post by Mark Millard via arm
. . .
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.
But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)
After booting with the reverted U-Boot related
# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media
# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin
The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).
If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
Looks like 2021.04 (even before 2021.04_1) also has the
problem for root-on-USB handling.
I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e
directory copy that was 2021.04 (and its boot.scr) but
before the UEFI change. When I tried it for the
root-on-USB context I still got the hangup after "Kernel
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
So it does not appear to be the UEFI change so much as
2021.04 in general for which the FreeBSD kernel and
the U-Boot are apparently(?) mismatched for root-on-USB.
Reverting again to 2020.10 U-Boot got back the root-on-USB
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47ef5000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm
. . .
Well, I got a surprise in exploring: removing boot.scr
and ubldr.bin did not prevent booting. (Noticed by the
accident of ending up with one of them missing that I
. . .
U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini
Type: Hard Disk
Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning usb 0:4...
30675 bytes read in 3 ms (9.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
. . .
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
|/-\|/FreeBSD/arm EFI loader, Revision 1.1
. . .
So I've likely been been booting via UEFI for
some time via 2020.10 (or even before?), just
without noticing at the time.
The other implication is likely that what disabled
root-on-USB for my context was not the boot.scr
removal material but some (possibly proper) subset
of other material changed (extracted from
Nope: I forgot that I've tried 2021.04 from before
the UEFI changes referenced, and also had the
problem for that context.

Still it is interesting that I'm getting a UEFI
boot context from 2020.10 .
Post by Mark Millard via arm
. . .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Emmanuel Vadot
2021-06-02 09:01:13 UTC
Permalink
On Sun, 30 May 2021 22:32:38 -0700
Post by Mark Millard via arm
Post by Mark Millard via arm
Post by Mark Millard via arm
Post by Mark Millard via arm
. . .
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.
But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)
After booting with the reverted U-Boot related
# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media
# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin
The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).
If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
Looks like 2021.04 (even before 2021.04_1) also has the
problem for root-on-USB handling.
I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e
directory copy that was 2021.04 (and its boot.scr) but
before the UEFI change. When I tried it for the
root-on-USB context I still got the hangup after "Kernel
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
So it does not appear to be the UEFI change so much as
2021.04 in general for which the FreeBSD kernel and
the U-Boot are apparently(?) mismatched for root-on-USB.
Reverting again to 2020.10 U-Boot got back the root-on-USB
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47ef5000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm
. . .
Well, I got a surprise in exploring: removing boot.scr
and ubldr.bin did not prevent booting. (Noticed by the
accident of ending up with one of them missing that I
. . .
U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini
Type: Hard Disk
Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning usb 0:4...
30675 bytes read in 3 ms (9.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
. . .
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
|/-\|/FreeBSD/arm EFI loader, Revision 1.1
. . .
So I've likely been been booting via UEFI for
some time via 2020.10 (or even before?), just
without noticing at the time.
The other implication is likely that what disabled
root-on-USB for my context was not the boot.scr
removal material but some (possibly proper) subset
of other material changed (extracted from
Nope: I forgot that I've tried 2021.04 from before
the UEFI changes referenced, and also had the
problem for that context.
2021.04 cannot work on armv7, caches weren't cleared.
Post by Mark Millard via arm
Still it is interesting that I'm getting a UEFI
boot context from 2020.10 .
The only thing I can suggest is git bisect on u-boot repo and see if
you have any result.
Post by Mark Millard via arm
Post by Mark Millard via arm
. . .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
--
Emmanuel Vadot <***@bidouilliste.com> <***@freebsd.org>
Mark Millard via arm
2021-06-02 10:40:03 UTC
Permalink
Post by Emmanuel Vadot
On Sun, 30 May 2021 22:32:38 -0700
Post by Mark Millard via arm
Post by Mark Millard via arm
Post by Mark Millard via arm
Post by Mark Millard via arm
. . .
I do not know if the FreeBSD kernel has been depending
on some U-Boot initialization for root-on-USB and the
two no longer match or what.
But I've used a release/13.0.0.0 microsd card based
boot to get older U-Boot materials (Quarterly as it
turns out). Installing such got me back to having a
root-on-USB boot of the OPi+2e (other than the
mircosd card having the older U-Boot (2020.10 as it
turns out). Of course there is also the matching
boot.scr involved --but it also is on the USB SSD.
(Similarly reverted RPi2 U-Boot, other than needing
to switch boot.scr to match.)
After booting with the reverted U-Boot related
# mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt
# mount -onoatime /dev/mmcsd1s2a /media
# ls -Tla /mnt/
total 20
drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
# ls -Tla /media/
total 60
drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 .
drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 ..
-rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin
The media is also set up for booting an RPi2 via
root-in-USB ( other than bootcode.bin ).
If FreeBSD and the more modern U-Boot were well matched
for USB support, I'd expect that this sort of thing would
work (no boot.scr needed).
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)
Looks like 2021.04 (even before 2021.04_1) also has the
problem for root-on-USB handling.
I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e
directory copy that was 2021.04 (and its boot.scr) but
before the UEFI change. When I tried it for the
root-on-USB context I still got the hangup after "Kernel
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47eea000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
So it does not appear to be the UEFI change so much as
2021.04 in general for which the FreeBSD kernel and
the U-Boot are apparently(?) mismatched for root-on-USB.
Reverting again to 2020.10 U-Boot got back the root-on-USB
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47ef5000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm
. . .
Well, I got a surprise in exploring: removing boot.scr
and ubldr.bin did not prevent booting. (Noticed by the
accident of ending up with one of them missing that I
. . .
U-Boot SPL 2020.10 (Apr 19 2021 - 18:04:31 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2020.10 (Apr 19 2021 - 18:04:31 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
. . .
Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini
Type: Hard Disk
Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning usb 0:4...
30675 bytes read in 3 ms (9.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
. . .
Booting /efi\boot\bootarm.efi
Consoles: EFI console
|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Reading loader env vars from /efi/freebsd/loader.env
|/-\|/FreeBSD/arm EFI loader, Revision 1.1
. . .
So I've likely been been booting via UEFI for
some time via 2020.10 (or even before?), just
without noticing at the time.
The other implication is likely that what disabled
root-on-USB for my context was not the boot.scr
removal material but some (possibly proper) subset
of other material changed (extracted from
Nope: I forgot that I've tried 2021.04 from before
the UEFI changes referenced, and also had the
problem for that context.
2021.04 cannot work on armv7, caches weren't cleared.
Post by Mark Millard via arm
Still it is interesting that I'm getting a UEFI
boot context from 2020.10 .
The only thing I can suggest is git bisect on u-boot repo and see if
you have any result.
Just FYI:

As a cross check, I tried the U-Boot 2021.04 from fedora 34's

uboot-images-armv7-2021.04-3.fc34.noarch.rpm

and its (as installed):

/usr/share/uboot/orangepi_plus2e/u-boot-sunxi-with-spl.bin

The overall boot also hangs, with slightly different messaging:

. . .
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x47f00000.
Kernel entry at 0xb2e00200...
Kernel args: (null)
EHCI failed to shut down host controller.

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

Loading...