Re: uBoot broken on RPI2 Model B?
- Reply: Karl Denninger : "Re: uBoot broken on RPI2 Model B?"
- Reply: Mark Millard : "Re: uBoot broken on RPI2 Model B?"
- In reply to: Mark Millard : "Re: uBoot broken on RPI2 Model B?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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]/