Bug 255366 - Only a single cpu detected on RP3
Summary: Only a single cpu detected on RP3
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-RELEASE
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-24 14:31 UTC by chris
Modified: 2021-04-25 17:11 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chris 2021-04-24 14:31:50 UTC
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
Comment 1 Mark Millard 2021-04-25 00:03:57 UTC
(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.)
Comment 2 Mark Millard 2021-04-25 02:53:04 UTC
(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 .
Comment 3 chris 2021-04-25 10:01:05 UTC
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
Comment 4 Mark Millard 2021-04-25 17:11:59 UTC
(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.