From nobody Sat Mar 04 01:48:04 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PT76H2d2Nz3wbj5 for ; Sat, 4 Mar 2023 01:48:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PT76G31J1z4Z7L for ; Sat, 4 Mar 2023 01:48:38 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id A84C8211087 for ; Fri, 3 Mar 2023 20:48:07 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 45AB1296A6B for ; Fri, 3 Mar 2023 20:48:07 -0500 (EST) Message-ID: <7284938e-2a69-af4a-e36e-dccce30e77d0@denninger.net> Date: Fri, 3 Mar 2023 20:48:04 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: uBoot broken on RPI2 Model B? Content-Language: en-US To: freebsd-arm@freebsd.org References: From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060704070804000402080506" X-Spamd-Result: default: False [-4.88 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx:c]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PT76G31J1z4Z7L X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N 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 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
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 2023     root@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-- --------------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--