Re: /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)"

On 2021-Jun-2, at 02:01, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Sun, 30 May 2021 22:32:38 -0700
> Mark Millard via arm <[email protected]> wrote:
> 
>> On 2021-May-30, at 22:27, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> On 2021-May-24, at 20:10, Mark Millard <marklmi at yahoo.com> wrote:
>>> 
>>>> On 2021-May-24, at 15:53, Mark Millard <marklmi at yahoo.com> wrote:
>>>> 
>>>>> On 2021-May-13, at 12:03, Mark Millard <marklmi at yahoo.com> wrote:
>>>>> 
>>>>>>>>> . . .
>>>>> 
>>>>> 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)
>>>> 
>>>> 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 ([email protected]:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
>>>> . . .
>>>> 
>>> 
>>> 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):
>> 
>> 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.
> 
>> 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)