Hi, main-n245392-8423f5d4c12 built 11th March won't boot due to microsd timeout. A kernel.old made from main-n244802-88db1cc9f19 on the same sdcard with the same rpi4b hardware and the same materials on the msdos partition does not have this problem. These are no-debug kernels, built with the same kernel config file. I have tried booting without anything attached to usb and it still fails at the same place. Running fsck on the microsd in another machine for both the msdos and the freebsd partitions makes no difference. Full console output is at https://cloud.zyxst.net/~john/FreeBSD/main-n245392-8423f5d4c12-no-debug-failboot.txt Thread on freebsd-arm@ is https://lists.freebsd.org/pipermail/freebsd-arm/2021-March/023323.html [...] sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: ============== REGISTER DUMP ============== sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 sdhci_bcm0-slot0: Argument: 0x01dacbc1 | Trn mode: 0x00000036 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =========================================== mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout [...] Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for 3 more seconds Mounting from ufs:/dev/ufs/rootfs failed with error 2. Loader variables: vfs.root.mountfrom=ufs:/dev/ufs/rootfs vfs.root.mountfrom.options=rw Manual root filesystem specification: <fstype>:<device> [options] Mount <device> using filesystem <fstype> and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) <empty line> Abort manual input mountroot> ufs:/dev/mmcsd0s2a Trying to mount root from ufs:/dev/mmcsd0s2a []... Mounting from ufs:/dev/mmcsd0s2a failed with error 2; retrying for 3 more seconds Mounting from ufs:/dev/mmcsd0s2a failed with error 2. mountroot> ufs:/dev/ufs/rootfs Trying to mount root from ufs:/dev/ufs/rootfs []... Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for 3 more seconds Mounting from ufs:/dev/ufs/rootfs failed with error 2. [...]
Note: As I understand things, this submittal is based in part on using: A) Possibly based on old RPi* firmware but which vintage is unknown. B) An old u-boot (2020.07, not 2020.10). C) An old loader.efi (as bootaa64.efi). For (A) it would help if the output of # strings start4.efi | grep VC_BUILD_ID_ was reported so that the context was better known. (Not seen so far on the lists either.) Notes abourt (B) and (C) are in the referenced list material. I have recommended that trying with all of this updated and reporting on the results so that the reporting context and investigation context would be matched without trying to revet to the odd mix of history now apparently involved. I'll note that the content from a few commits earlier: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz does not show this problem on teh RPi4B 8 GiByte that I tried (but you need to avoid USB storage media becuase of another issue that would cause a debug-kernel panic).
I'll test again with a newer image as the msdos partition has files from last year
root@generic:/boot/msdos # find . -type f -name start4.efi root@generic:/boot/msdos #
root@generic:/boot/msdos # find . -type f -name start4.efi root@generic:/boot/msdos # strings start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 10:59:17 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Jul 17 2020 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 21a15cb094f41c7506ad65d2cb9b29c550693057 (clean)
(In reply to Mark Millard from comment #1) start4.efi : should have been starte.elf Sorry.
Going in another test direction, I took the media I made via: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz and used the kernel.txz and kernel-dbg.txz from: https://artifact.ci.freebsd.org/snapshot/main/8423f5d4c127f18e7500bc455bc7b6b1691385ef/arm64/aarch64/ to update the media to match the vintage of kernel being reported on, although it is a debug kernel for snapshots. (The matching artifact snapshot happened to exist for aarch64. That does not always happen.) The media booted just fine all the way to the login prompt. (No USB storage media attached because of another issue with this vintage for debug kernels.) For reference: # uname -apKU FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 8423f5d: Thu Mar 11 18:15:35 UTC 2021 root@FreeBSD-main-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1400005 1400005 So: 8423f5d4c12 does not fail with modern materials on the msdosfs file system, at least for the debug kernel build. That suggests: Not a bug.
(In reply to Mark Millard from comment #5) Trying to type correctly for once: start4.efi and starte.elf: should have been start4.elf
I saved the working kernel.old image and wrote FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img to the microsd, added latest start4.elf and fixup4.dat and u-boot and confirm this won't boot with usb stuff attached, which I think is a different issue. closing this one