I have just upgraded to FreeBSD 13.0-RELEASE from 12.2 for my Raspberry PI 3+. On booting the kernel detects only a single CPU: dmesg output: VT(efifb): resolution 656x416 real memory = 993951744 (947 MB) avail memory = 947949568 (904 MB) Starting CPU 1 (1) Starting CPU 1 (2) Starting CPU 1 (3) FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs and: [tmp]# sysctl dev.cpu dev.cpu.3.%parent: cpulist0 dev.cpu.3.%pnpinfo: name=cpu@3 compat=arm,cortex-a53 dev.cpu.3.%location: dev.cpu.3.%driver: cpu dev.cpu.3.%desc: Open Firmware CPU dev.cpu.2.%parent: cpulist0 dev.cpu.2.%pnpinfo: name=cpu@2 compat=arm,cortex-a53 dev.cpu.2.%location: dev.cpu.2.%driver: cpu dev.cpu.2.%desc: Open Firmware CPU dev.cpu.1.%parent: cpulist0 dev.cpu.1.%pnpinfo: name=cpu@1 compat=arm,cortex-a53 dev.cpu.1.%location: dev.cpu.1.%driver: cpu dev.cpu.1.%desc: Open Firmware CPU dev.cpu.0.temperature: 36.4C dev.cpu.0.freq_levels: 1400/-1 600/-1 dev.cpu.0.freq: 600 dev.cpu.0.%parent: cpulist0 dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a53 dev.cpu.0.%location: dev.cpu.0.%driver: cpu dev.cpu.0.%desc: Open Firmware CPU dev.cpu.%parent Can't find any similar bugs, and I think my kernel config is OK, and have checked the release notes. What have I missed,or is this a bug? Thanks Chris
(I'm having to make very general suggestions, given the limited evidence presented.) It seems likely that the debug reporting from the RPi firmware and/or u-boot reports some sort of problem before the FreeBSD loader is even started. This in turn tends to involve use of a recording serial console output. (I've no clue if you are currently set up for such recording.) The RPi firmware's config.txt can contain: enable_uart=1 uart_2ndstage=1 dtdebug=1 to enable some of the RPi firmware debugging. https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md reports that the following can enable additional BOOT_UART debug output (linux is their context): sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin You might want to first check via the recommended: $ strings bootcode.bin | grep BOOT_UART to see if BOOT_UART is there to update and if the value needs updating for the purpose: it add more debugging output. If you have tailored the config.txt in other ways, you should report what you have in the file. If you can have access to the microsd card from some other means of booting, you could use the following sort of command to find and report for sure on the RPi firmware version (shown with example output): # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 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) You are not clear if you started from scratch dd'ing FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img to a microsd card or used some other procedure. If you have a spare microsd card available, you might want to do such a dd to it and see if the result boots okay. If it did, that would indicate some about what is still out of date in your already-existing (possibly partial) upgrade. Upgrading RPi media requires updating more than FreeBSD. There is the sysutils/rpi-firmware material and the sysutils/u-boot-rpi-arm64 material as well. Such materials are involved in the boot before FreeBSD kernel or FreeBSD loader are involved. /usr/local/share/rpi-firmware/ and /usr/local/share/u-boot/u-boot-rpi-arm64/ are where the ports/packages put the material that is to be copied to the msdos file system on the microsd card. If you have other access to the microsd card content, you could do a command like (shown with example output): # strings u-boot.bin | grep 'U-Boot 2' U-Boot 2021.04 (Apr 08 2021 - 10:46:22 +0000) to find and report for sure on the u-boot version present. (FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img contains a 2020.10 based version, not the newer one shown above.)
(In reply to Mark Millard from comment #1) The sed is likely better written for FreeBSD as something like: sed -i .bak -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin Otherwise the unmodified (but renamed) file ends up with a name like bootcode.bin-e instead of something like bootcode.bin.bak .
Hi, many thanks for your reply. I had upgraded in place and had not upgraded the boot code on the MSDOS partition. I've done this using the boot code on the RPI 13.0 image, and all now works as expected. You can close this now. Cheers Chris
(In reply to chris from comment #3) I do not have permissions to close this for you. I can do such only for my own submittals.