Somewhere seemingly recently, RPI3 images fail to boot due to failing to load /boot/loader.efi. I have so far been unsuccessful bisecting which change(s) introduced the problem, but it can be observed with the most recent RPI3 images on the download mirrors: https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180426-r333017.img.xz The output observed follows. >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: /\efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) Probing 3 block devices...... done ZFS found no pools UFS found no partitions Failed to load '/boot/loader.efi' panic: No bootable partitions found! ## Application terminated, r = 1 EFI LOAD FAILED: continuing... Device 0: unknown device Waiting for Ethernet connection... done. BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3
What version of U-Boot are you using and has it changed since the last working snapshot?
I highly suspect an out of date u-boot-rpi3 as r332500 boots on rpi3 here
https://reviews.freebsd.org/rP468630
Missing patches in the port also affect boot but in a different way. This particular failure is not due to them. So far I found following: 20180412 image boots loader.efi and proceeds to load the kernel and hangs due to missing port patches. 20180412 with FAT partition content from 20180426 behaves the same way 20180426 with FAT partition content from 20180412 fails just like 20180426 So my guess the problem is in partition layout. 20180412 (in sectors): Device Boot Start End Blocks Id System /dev/md0s1 * 2048 104447 51200 c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary. /dev/md0s2 104448 5242879 2569216 a5 FreeBSD Partition 2 does not end on cylinder boundary. 20180426 (in sectors): Device Boot Start End Blocks Id System /dev/md1s1 * 2079 104390 51156 c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary. /dev/md1s2 104391 5242859 2569234+ a5 FreeBSD Partition 2 does not end on cylinder boundary.
For me it has to do with kern.geom.part.mbr.enforce_chs=1 that was set on the build machines recently. (not tested but pine64 images are also affected this rolls u-boot out as it hasn't changed for this board.). We need to test if putting loader.efi as bootaa64.efi works correctly since Warner latest modification and just forgot about boot1.efi for arm64. I'll try to test this today for pine64 and overdrive 1000 (and maybe rpi3 if I have time).
(In reply to Emmanuel Vadot from comment #5) loader.efi as bootaa64.efi boots fine on the latest release image, I tested it today but forgot to mention
I'm seeing the same behavior as Glen with the latest RPI3 image, FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180509-r333409.img on a RPI 3B+ (well, it's the same up to where u-boot tries to access the ethernet chip, and then it complains "No ethernet found" and drops back to a U-Boot> prompt). I tried replacing bootaa64.efi with /boot/loader.efi as suggested, and then it gets through booting the kernel all right, but hangs up at mountroot: mountroot: waiting for device /dev/ufs/rootfs... Mounting from ufs:/dev/ufs/rootfs failed with error 19. after which it asks for a manual root specification. I am suspicious that Emmanuel has the right idea in comment #5: there is something fishy about the way the main UFS filesystem has been set up on the SD card image. That's a separate problem from the old-bootloader problem.
(In reply to Tom Lane from comment #7) > ... but it hangs up at mountroot Oh! After looking more closely at the dmesg output, I realized that the problem is the kernel's not talking to the SD card at all: sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x7e300000-0x7e3000ff irq 46 on simplebus0 mmc0: <MMC/SD bus> on sdhci_bcm0 ... mmc0: No compatible cards found on bus I was able to get it to boot via the expedient of making a second identical SD card image and plugging that in with a USB SD card reader, so that the kernel is booted off the internal SD card and then it finds and mounts the main file system on the USB "disk". Wotta kluge, but maybe that's expected missing-hardware-support at present? Anyway, replacing bootaa64.efi as suggested seems to be enough to resolve the bug discussed here; other shortcomings in RPI 3B+ support ought to be separate bugs.
We switched to loader.efi as bootaa64.efi