Bug 234778 - Only 1 CPU core out of 4 is usable on RPi2 v1.2
Summary: Only 1 CPU core out of 4 is usable on RPi2 v1.2
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 12.0-STABLE
Hardware: arm Any
: --- Affects Only Me
Assignee: freebsd-arm mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-09 07:31 UTC by t_uemura
Modified: 2019-10-08 05:18 UTC (History)
2 users (show)

See Also:


Attachments
v1.1 dmesg (15.82 KB, text/plain)
2019-01-09 07:31 UTC, t_uemura
no flags Details
v1.1 sysctl (2.04 KB, text/plain)
2019-01-09 07:32 UTC, t_uemura
no flags Details
v1.1 top (2.29 KB, text/plain)
2019-01-09 07:32 UTC, t_uemura
no flags Details
v1.2 dmesg (15.82 KB, text/plain)
2019-01-09 07:32 UTC, t_uemura
no flags Details
v1.2 sysctl (2.04 KB, text/plain)
2019-01-09 07:33 UTC, t_uemura
no flags Details
v1.2 top (2.29 KB, text/plain)
2019-01-09 07:33 UTC, t_uemura
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description t_uemura 2019-01-09 07:31:05 UTC
The architecture of recent 12-STABLE for RPi2 (32 bit) is armv7, rather than armv6 on 11-STABLE. This means that there is a chance that the same build can run also on RPi2 v1.2 equipped with the newer ARMv8 based BCM2837 SoC.

Actually, the build works almost perfectly on v1.2 board except one big issue, that only 1 CPU logical core is used/assigned to all processes and the remaining 3 cores are completely ignored, despite all 4 cores are listed in top, for example.

This doesn't happen on v1.1 board. The same microSD (just pulled out from v1.2 board) runs fine on v1.1 board. I can't see any significant differences between both boards in top, dmesg or sysctl output.

The OS is r341492, rpi-firmware is 1.20180619 or the GIT rev. 077fbe8 (as of 6th Dec. 2018) and u-boot is 2018.11.
Comment 1 t_uemura 2019-01-09 07:31:56 UTC
Created attachment 200941 [details]
v1.1 dmesg
Comment 2 t_uemura 2019-01-09 07:32:16 UTC
Created attachment 200942 [details]
v1.1 sysctl
Comment 3 t_uemura 2019-01-09 07:32:32 UTC
Created attachment 200943 [details]
v1.1 top
Comment 4 t_uemura 2019-01-09 07:32:51 UTC
Created attachment 200944 [details]
v1.2 dmesg
Comment 5 t_uemura 2019-01-09 07:33:09 UTC
Created attachment 200945 [details]
v1.2 sysctl
Comment 6 t_uemura 2019-01-09 07:33:26 UTC
Created attachment 200946 [details]
v1.2 top
Comment 7 Emmanuel Vadot freebsd_committer 2019-01-10 05:04:11 UTC
That's weird that I've never seen that.
We would need to support the "brcm,bcm2836-smp" enable method to bring up the others cpus.
I have plan to work on enable methods (as we need psci for armv7 when booting in hyp mode) but I don't know when I will have time.
Comment 8 t_uemura 2019-10-08 05:18:17 UTC
Reply to myself. This issue is likely relating to the following upstream bug,
https://github.com/raspberrypi/linux/issues/3234

and may be fixed in the following raspberrypi/firmware commit.
https://github.com/raspberrypi/firmware/commit/7f607df21c0e255fee80a783721b11d460cbb49b

I'll give it a try in the near future.