Re: uBoot broken on RPI2 Model B?

From: Karl Denninger <karl_at_denninger.net>
Date: Sat, 04 Mar 2023 01:48:04 UTC
On 3/3/2023 19:36, Mark Millard wrote:
> On Mar 3, 2023, at 14:50, Karl Denninger<karl@denninger.net>  wrote:
>
>> On 3/3/2023 16:12, Karl Denninger wrote:
>>> Just tried to build -13STABLE for the RPi2
> v1.1 (so: armv7) (I'll be testing this case.)
> v1.2 (so: aarch64 --but could also be used via armv7)
>
>>> and ran into this (I'm using Crochet and have had to make some changes to the board-specific files, but it appears the problem that results in it not working is in uboot; I've made a number of changes since it looks like the system now wants to boot off EFI as opposed to what worked in -12, which would be ok if it can find the boot device -- I think (may be wrong here)
>>> U-Boot 2023.01 (Jan 26 2023 - 04:25:18 +0000)
>>>
>>> DRAM:  948 MiB
>>> RPI 2 Model B (0xa21041)
>>> Core:  70 devices, 13 uclasses, devicetree: board
>>> MMC:   mmc@7e300000: 1
>>> Loading Environment from FAT... ** Bad device specification mmc 0 **
>>> In:    serial
>>> Out:   vidconsole
>>> Err:   vidconsole
>>> Net:   No ethernet found.
>>> starting USB...
>>> Bus usb@7e980000: USB DWC2
>>> scanning bus usb@7e980000 for devices... 3 USB Device(s) found
>>>         scanning usb for storage devices... 0 Storage Device(s) found
>>> Hit any key to stop autoboot:  0
>>> U-Boot>
>>> Needless to say if I let it try to continue it fails as it can't find the SD card and "mmc dev" shows nothing present.
>>> Obviously going to dig into this further myself but I recalled something about this uBoot version being broken on older Pis...
>>> The layout of the disk on the boot partition is thus:
>>> root@NewFS:/mnt # ls -la
>>> total 12679
>>> drwxr-xr-x   1 root  wheel    16384 Dec 31  1979 .
>>> drwxr-xr-x  35 root  wheel       42 Jan 20 10:16 ..
>>> drwxr-xr-x   1 root  wheel     4096 Feb 13 11:09 EFI
>>> -rwxr-xr-x   1 root  wheel      709 Feb 13 11:09 README
>>> -rwxr-xr-x   1 root  wheel    26745 Feb 13 11:09 bcm2709-rpi-2-b.dtb
> So: armv7 style.

Yes.  I didn't think I COULD build for aarch64 on the Pi2.... that will 
work?


>>> -rwxr-xr-x   1 root  wheel    52456 Feb 13 11:09 bootcode.bin
>>> -rwxr-xr-x   1 root  wheel      141 Feb 13 11:09 config.txt
>>> -rwxr-xr-x   1 root  wheel     7314 Feb 13 11:09 fixup.dat
>>> -rwxr-xr-x   1 root  wheel     3187 Feb 13 11:09 fixup_cd.dat
>>> -rwxr-xr-x   1 root  wheel    10298 Feb 13 11:09 fixup_db.dat
>>> -rwxr-xr-x   1 root  wheel    10298 Feb 13 11:09 fixup_x.dat
>>> drwxr-xr-x   1 root  wheel    20480 Feb 13 11:09 overlays
>>> -rwxr-xr-x   1 root  wheel    21169 Feb 13 11:09 rpi2.dtb
> RPi* firmware does not include such a rpi2.dtb . It
> is some sort of addition to the materials. My context
> will not have it.
After I get through this message I will remove it and see if that 
changes anything (so far nothing else has.)
>>> -rwxr-xr-x   1 root  wheel  2952960 Feb 13 11:09 start.elf
> The following sort of thing could help confirm the
> match to what is in the official snapshot builds
> at this point:
>
> For example, for what I later report on testing
> (an official snapshot build installation):
>
> # strings /mnt/start.elf | grep VC_BUILD_ID_
> VC_BUILD_ID_USER: dom
> VC_BUILD_ID_TIME: 12:12:09
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
root@NewFS:/mnt # strings start.elf|grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:12:09
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

Identical.

>>> -rwxr-xr-x   1 root  wheel   793116 Feb 13 11:09 start_cd.elf
>>> -rwxr-xr-x   1 root  wheel  4794472 Feb 13 11:09 start_db.elf
>>> -rwxr-xr-x   1 root  wheel  3704808 Feb 13 11:09 start_x.elf
>>> -rwxr-xr-x   1 root  wheel   521916 Feb 13 11:09 u-boot.bin
> For reference:
>
> # strings /mnt/u-boot.bin | grep "U-Boot 202"
> U-Boot 2023.01 (Mar 02 2023 - 02:41:45 +0000)

root@NewFS:/mnt # strings u-boot.bin | grep 'U-Boot 202'
U-Boot 2023.01 (Jan 26 2023 - 04:25:18 +0000)

This is the latest one I have, from:

u-boot-rpi2-2023.01            Cross-build das u-boot for model rpi2

My crossbuild host says I have no updates available via the pkg system.

> As for the bootarm.efi , as I remember there is no good
> string to show. So I'll show just:
>
> # ls -Tld /mnt/EFI/BOOT/bootarm.efi
> -rwxr-xr-x  1 root  wheel  1407668 Mar  1 19:55:18 2023 /mnt/EFI/BOOT/bootarm.efi
root@NewFS:/mnt # ls -Tld EFI/BOOT/bootarm.efi
-rwxr-xr-x  1 root  wheel  133812 Feb 13 11:09:16 2023 EFI/BOOT/bootarm.efi

Definitely not the same.

>>> root@NewFS:/mnt # ls -laR EFI
>>> total 24
>>> drwxr-xr-x  1 root  wheel   4096 Feb 13 11:09 .
>>> drwxr-xr-x  1 root  wheel  16384 Dec 31  1979 ..
>>> drwxr-xr-x  1 root  wheel   4096 Feb 13 11:09 BOOT
>>>
>>> EFI/BOOT:
>>> total 140
>>> drwxr-xr-x  1 root  wheel    4096 Feb 13 11:09 .
>>> drwxr-xr-x  1 root  wheel    4096 Feb 13 11:09 ..
>>> -rwxr-xr-x  1 root  wheel  133812 Feb 13 11:09 bootarm.efi
>>> root@NewFS:/mnt # more config.txt
>>> init_uart_clock=3000000
>>> enable_uart=1
>>> kernel=u-boot.bin
>>> kernel7=u-boot.bin
>>> dtoverlay=mmc
> The snapshot materials do not have the followin
> 2 lines in the config.txt but do have the above:
>
>>> audio_pwm_mode=2
>>> dtparam=audio=on,i2c_arm=on,spi=on
Yes, those have to be there for the audio to work and for i2c inputs, 
which I do use.
>>> root@NewFS:/mnt # ls -la overlays | grep mmc
>>> -rwxr-xr-x  1 root  wheel    1221 Feb 13 11:09 mmc.dtbo
>>> Which I BELIEVE should work -- assuming that I can get "see" the SD card from u-boot that is....
>>> Installed rpi-related packages:
>>> root@NewFS:/mnt # pkg info|grep rpi
>>> rpi-firmware-1.20210303.g20210303 Firmware for RaspberryPi Single Board Computer
>>> u-boot-rpi2-2023.01            Cross-build das u-boot for model rpi2
>>> u-boot-rpi3-2023.01            Cross-build das u-boot for model rpi3
>>> u-boot-rpi4-2023.01            Cross-build das u-boot for model rpi4
> For reference: the gpart show output lines for
> the microsd card media in a reader were like:
>
> =>       63  249737153  da3  MBR  (119G)
>           63       1985       - free -  (993K)
>         2048     102400    1  fat32lba  [active]  (50M)
>       104448   10381312    2  freebsd  (5.0G)
>     10485760  239251456       - free -  (114G)
>
> =>       0  10381312  da3s2  BSD  (5.0G)
>           0       128         - free -  (64K)
>         128  10381184      1  freebsd-ufs  (4.9G)
>
> (It will change if it boots in the RPi2 v1.1 .)
>
>> I found a copy of the 2022-10 uboot:
>> U-Boot 2022.10 (Oct 24 2022 - 02:01:47 +0000)
>>
>> DRAM:  948 MiB
>> RPI 2 Model B (0xa21041)
>> Core:  70 devices, 13 uclasses, devicetree: board
>> MMC:   mmc@7e300000: 1
>> Loading Environment from FAT... ** Bad device specification mmc 0 **
>> In:    serial
>> Out:   vidconsole
>> Err:   vidconsole
>> Net:   No ethernet found.
>> starting USB...
>> Bus usb@7e980000: USB DWC2
>> scanning bus usb@7e980000 for devices... 3 USB Device(s) found
>>         scanning usb for storage devices... 0 Storage Device(s) found
>> Hit any key to stop autoboot:  0
>>
>>>> FreeBSD EFI boot block
>>     Loader path: /boot/loader.efi
>>
>>     Initializing modules: ZFS UFS
>>     Load Path: /efi\boot\bootarm.efi
>>     Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,MBR,0xb5048a37,0x3f,0x18fe7)
>>     Probing 3 block devices...not supported
>> not supported
>> not supported
>>   done
>>      ZFS found no pools
>>      UFS found no partitions
>> Failed to load '/boot/loader.efi'
>> panic: No bootable partitions found!
>> ## Application failed, r = 1
>> Can't remove invalid handle 00000000
>> EFI LOAD FAILED: continuing...
>> MMC Device 2 not found
>> no mmc device at slot 2
>>
>> Device 0: unknown device
>> Waiting for Ethernet connection... unable to connect.
>> missing environment variable: pxeuuid
>> Retrieving file: pxelinux.cfg/01-b8-27-eb-0d-05-01
>> Waiting for Ethernet connection...
>> Hmmm... going back and looking at the 2023-01 version boot sequence again... same thing it appears; the u-boot DOES load the EFI loader, but dies there.  Am I trying to be too cute by half and should stick ubldr.bin in that boot partition and get rid of the EFI loader entirely?
>>
> To test, I grabbed the official snapshot build:
>
> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20230302-3912f99ecae6-254729.img.xz
>
> Then I did an unxz in the file that resulted and then
> dd'd the .img file to a microsd card:
>
> dd if=FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20230302-3912f99ecae6-254729.img of=/dev/da3 bs=1m conv=sync,fsync status=progress
>
> So I plugged in the microsd card to the RPi2 v1.1 and
> powered on.
>
> It booted just fine.
>
> # gpart show
> =>       63  249737153  mmcsd0  MBR  (119G)
>           63       1985          - free -  (993K)
>         2048     102400       1  fat32lba  [active]  (50M)
>       104448  249628672       2  freebsd  (119G)
>    249733120       4096          - free -  (2.0M)
>
> =>        0  249628672  mmcsd0s2  BSD  (119G)
>            0        128            - free -  (64K)
>          128  245876608         1  freebsd-ufs  (117G)
>    245876736    3751936         2  freebsd-swap  (1.8G)
>
> # uname -apKU
> FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE #0 stable/13-n254729-3912f99ecae6: Thu Mar  2 04:05:56 UTC 2023root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC  arm armv7 1302503 1302503
>
> # freebsd-version -kru
> 13.2-STABLE
> 13.2-STABLE
> 13.2-STABLE
>
> # find -s /boot/msdos/ -print
> /boot/msdos/
> /boot/msdos/EFI
> /boot/msdos/EFI/BOOT
> /boot/msdos/EFI/BOOT/bootarm.efi
> /boot/msdos/MLO
> /boot/msdos/bcm2709-rpi-2-b.dtb
> /boot/msdos/bootcode.bin
> /boot/msdos/config.txt
> /boot/msdos/dtb
> . . .
> /boot/msdos/dtb/zybo.dtb
> /boot/msdos/fixup.dat
> /boot/msdos/fixup_cd.dat
> /boot/msdos/fixup_db.dat
> /boot/msdos/fixup_x.dat
> /boot/msdos/overlays
> /boot/msdos/overlays/mmc.dtbo
> /boot/msdos/start.elf
> /boot/msdos/start_cd.elf
> /boot/msdos/start_db.elf
> /boot/msdos/start_x.elf
> /boot/msdos/u-boot.bin
> /boot/msdos/u-boot.img
>
> # swapinfo
> Device          1K-blocks     Used    Avail Capacity
> /dev/label/growfs_swap   1875964        0  1875964     0%
>
> # dumpon -vl
> kernel dumps on priority: device
> 0: /dev/null
>
> (That last is probably not as intended yet.)
>
>
> ===
> Mark Millard
> marklmi at yahoo.com

Hmmmm....

I will grab the "latest" and compare.  The difference has to lie in 
there /somewhere /since the snapshot does boot (I was looking for the 
correct one and wasn't sure which one it was -- thanks/.)/

It appears that the boot environment u-boot uses defaults to mmc 0, but 
mmc0 does not exist.  Mmc 1 /does; /from the u-boot prompt if I escape 
out I can select mmc 1 and, having done so, I can see the device//(its 
characteristics show up once I select it/.)/

What appears to be happening, however, is that the EFI loader thinks it 
came from and thus should boot from 0, and fails as there's nothing 
there.  Trying to get cute and use ubldr.bin instead didn't get me 
anywhere either (I have an old boot.scr file which, when included, does 
load the ubldr image but it hangs when it tries to start it and I can't 
escape out of it.)

Here's one thing that I found, and its probably the issue -- from the 
snapshot:

root@NewFS:/mnt2 # ls -al EFI/BOOT
total 1384
drwxr-xr-x  1 root  wheel     4096 Mar  1 23:36 .
drwxr-xr-x  1 root  wheel     4096 Mar  1 23:36 ..
-rwxr-xr-x  1 root  wheel  1407668 Mar  1 22:55 bootarm.efi
root@NewFS:/mnt2 # file EFI/BOOT/bootarm.efi
EFI/BOOT/bootarm.efi: MS-DOS executable PE32 executable (EFI 
application) ARM Thumb, for MS Windows

And from what was built (implying that the build code picked up the 
*wrong* file, perhaps one missing things...)

root@NewFS:/mnt # ls -al EFI/BOOT
total 140
drwxr-xr-x  1 root  wheel    4096 Feb 13 11:09 .
drwxr-xr-x  1 root  wheel    4096 Feb 13 11:09 ..
-rwxr-xr-x  1 root  wheel  133812 Feb 13 11:09 bootarm.efi
root@NewFS:/mnt # file EFI/BOOT/bootarm.efi
EFI/BOOT/bootarm.efi: MS-DOS executable PE32 executable (EFI 
application) ARM Thumb, for MS Windows

That one runs, but can't find anything -- and is 1/10th the size of the 
one on the snapshot!  I will dig around and see if I can figure that one 
out, because the same "pickup" works as expected for the Pi3, so 
something odd is going on here.  A bit of swapping files around and I 
bet I can figure it out; will post back when I do.

Thanks.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/