Date: Fri, 3 Mar 2023 20:48:04 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: uBoot broken on RPI2 Model B? Message-ID: <7284938e-2a69-af4a-e36e-dccce30e77d0@denninger.net> In-Reply-To: <E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com> References: <a1ce1685-4d82-566e-ec35-a878592ebd0c@denninger.net> <b8ecf2c3-e0cd-3ca0-bd26-a678d915b721@denninger.net> <E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms060704070804000402080506 Content-Type: multipart/alternative; boundary="------------68sjdnkYVmVwMaxlOzcNK9b3" --------------68sjdnkYVmVwMaxlOzcNK9b3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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]/ --------------68sjdnkYVmVwMaxlOzcNK9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 3/3/2023 19:36, Mark Millard wrote:<br> </div> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <pre class="moz-quote-pre" wrap="">On Mar 3, 2023, at 14:50, Karl Denninger <a class="moz-txt-link-rfc2396E" href="mailto:karl@denninger.net"><karl@denninger.net></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On 3/3/2023 16:12, Karl Denninger wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Just tried to build -13STABLE for the RPi2 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> v1.1 (so: armv7) (I'll be testing this case.) v1.2 (so: aarch64 --but could also be used via armv7) </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> So: armv7 style.</pre> </blockquote> <p>Yes. I didn't think I COULD build for aarch64 on the Pi2.... that will work?</p> <p><br> </p> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">-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 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> RPi* firmware does not include such a rpi2.dtb . It is some sort of addition to the materials. My context will not have it.</pre> </blockquote> After I get through this message I will remove it and see if that changes anything (so far nothing else has.) <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">-rwxr-xr-x 1 root wheel 2952960 Feb 13 11:09 start.elf </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> 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) </pre> </blockquote> root@NewFS:/mnt # strings start.elf|grep VC_BUILD_ID_<br> VC_BUILD_ID_USER: dom<br> VC_BUILD_ID_TIME: 12:12:09<br> VC_BUILD_ID_VARIANT: start<br> VC_BUILD_ID_TIME: Feb 25 2021<br> VC_BUILD_ID_BRANCH: bcm2711_2<br> VC_BUILD_ID_HOSTNAME: buildbot<br> VC_BUILD_ID_PLATFORM: raspberrypi_linux<br> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)<br> <p>Identical. </p> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">-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 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> For reference: # strings /mnt/u-boot.bin | grep "U-Boot 202" U-Boot 2023.01 (Mar 02 2023 - 02:41:45 +0000)</pre> </blockquote> <p>root@NewFS:/mnt # strings u-boot.bin | grep 'U-Boot 202'<br> U-Boot 2023.01 (Jan 26 2023 - 04:25:18 +0000)<br> </p> <p>This is the latest one I have, from:</p> <p>u-boot-rpi2-2023.01 Cross-build das u-boot for model rpi2<br> </p> <p>My crossbuild host says I have no updates available via the pkg system. </p> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <pre class="moz-quote-pre" wrap="">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 </pre> </blockquote> root@NewFS:/mnt # ls -Tld EFI/BOOT/bootarm.efi<br> -rwxr-xr-x 1 root wheel 133812 Feb 13 11:09:16 2023 EFI/BOOT/bootarm.efi<br> <p>Definitely not the same. </p> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> The snapshot materials do not have the followin 2 lines in the config.txt but do have the above: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">audio_pwm_mode=2 dtparam=audio=on,i2c_arm=on,spi=on</pre> </blockquote> </blockquote> </blockquote> Yes, those have to be there for the audio to work and for i2c inputs, which I do use.<br> <blockquote type="cite" cite="mid:E08E3A80-E6F1-44BB-846D-1FC711E064BA@yahoo.com"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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 </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> 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 .) </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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 </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">FreeBSD EFI boot block </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> 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? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> To test, I grabbed the official snapshot build: <a class="moz-txt-link-freetext" href="http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20230302-3912f99ecae6-254729.img.xz">http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20230302-3912f99ecae6-254729.img.xz</a>; 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 2023 <a class="moz-txt-link-abbreviated" href="mailto:root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC">root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC</a> 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 </pre> </blockquote> <p>Hmmmm....</p> <p>I will grab the "latest" and compare. The difference has to lie in there <i>somewhere </i>since the snapshot does boot (I was looking for the correct one and wasn't sure which one it was -- thanks<i>.)</i></p> <p>It appears that the boot environment u-boot uses defaults to mmc 0, but mmc0 does not exist. Mmc 1 <i>does; </i>from the u-boot prompt if I escape out I can select mmc 1 and, having done so, I can see the device<i> </i>(its characteristics show up once I select it<i>.)</i></p> <p>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.)</p> <p>Here's one thing that I found, and its probably the issue -- from the snapshot:</p> <p>root@NewFS:/mnt2 # ls -al EFI/BOOT<br> total 1384<br> drwxr-xr-x 1 root wheel 4096 Mar 1 23:36 .<br> drwxr-xr-x 1 root wheel 4096 Mar 1 23:36 ..<br> -rwxr-xr-x 1 root wheel 1407668 Mar 1 22:55 bootarm.efi<br> root@NewFS:/mnt2 # file EFI/BOOT/bootarm.efi<br> EFI/BOOT/bootarm.efi: MS-DOS executable PE32 executable (EFI application) ARM Thumb, for MS Windows<br> </p> <p>And from what was built (implying that the build code picked up the *wrong* file, perhaps one missing things...)</p> <p>root@NewFS:/mnt # ls -al EFI/BOOT<br> total 140<br> drwxr-xr-x 1 root wheel 4096 Feb 13 11:09 .<br> drwxr-xr-x 1 root wheel 4096 Feb 13 11:09 ..<br> -rwxr-xr-x 1 root wheel 133812 Feb 13 11:09 bootarm.efi<br> root@NewFS:/mnt # file EFI/BOOT/bootarm.efi<br> EFI/BOOT/bootarm.efi: MS-DOS executable PE32 executable (EFI application) ARM Thumb, for MS Windows<br> </p> <p>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.<br> </p> <p>Thanks.<br> </p> <div class="moz-signature">-- <br> Karl Denninger<br> <a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br> <i>The Market Ticker</i><br> <font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div> </body> </html> --------------68sjdnkYVmVwMaxlOzcNK9b3-- --------------ms060704070804000402080506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAzMDQwMTQ4MDZaME8GCSqGSIb3DQEJBDFCBED0VkpAIDZ6nldYKv/0 IX9sEdX05YkRDH6iBUmmm4VvTIpfnxLr/ybnul1Zx7vM2JIXrQHjAlFVu6w9eAmNFeKzMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgAk1+jMCDkNB5I+A1zZDWEOi2Wuh4BllwVk143b 42pTEjzmoyI2HQdoL5YW6SncCDSZgA3rXDLGzkbAxkao5tUTGFZAUqS6gav+lNTNL/KXoHSZ H9HGyEwPLIuOsYGIIedw5JtkLDeEO0hzZkJux1PS+7yXS/xhtYzuFl+oWocbw/Us6uImdNQ4 PJmce2XK4C+q0B6ebhn4B111Bxw0aQ/FkCK5okQy4n109o4e0JksRTuBkuGLc+Udt24ksJQt 5k3CgOmqg06BEHNY+rOMqVRs+u7w9JSlom9jHCKm/uecIVsNmrAVaKChPUjVwmOzDcBvHac0 G8dFTGPdskIITYrTx7SWsFNyOEJPAzpEwQZZMiAlzjhiu6F2s/qBHn9UsXjRIB6hpvfjF9EM 8spZgMpJ1mdmJWypOhVJBD1nTsi7TrxqLsvepFdrik6USa3kUprLxQpZ/3RVVc3b1F+PhfFH 9F4O2GPXbDHOZYtRKTcK2/96B3G6btKlkNlmRLLKBNdLC1+/+fzR4uJWtFwP8RCihyWidnZc kMKqJUPJpZtysZ6qHjFaZpJc06eADBpbgqJQXWaWvmHpZgS02qF5optzEYdpgKQma5++ftZ9 hMoCeist0hIg1F0g1z2jB/DwCRIfhWoOy0zek5XKqvwjhyE7tSLObhwMHnYSLx6TN3InMAAA AAAAAA== --------------ms060704070804000402080506--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7284938e-2a69-af4a-e36e-dccce30e77d0>