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: Closed FIXED
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 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-09 07:31 UTC by t_uemura
Modified: 2020-08-19 07:03 UTC (History)
3 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
View All Add an attachment (proposed patch, testcase, etc.)

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 freebsd_triage 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.
Comment 9 Tom Jones freebsd_committer freebsd_triage 2020-07-11 18:08:50 UTC 
Can you report if the fix mentioned fixed the issue?

As a point of interest this bug seems to also indicate similar behaviour 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232204
Comment 10 t_uemura 2020-08-19 07:03:57 UTC 
(In reply to Tom Jones from comment #9)
Sorry for my late reply.

12-STABLE as of 20200727 w/ u-boot-rpi2-2020.07 and the recent firmware (*), I can't reproduce the issue I mentioned earlier. All 4 cores are detected, enabled and used correctly.

* https://github.com/raspberrypi/firmware/commit/8174b21b65f26e6b71aca63b6c4686ff583cccca#diff-881cc4157ed641a365a86452f27ed745