Added note for what @never_released mentions: The two Denver cores have different performance metrics, and tend to be disabled until a user wants to dedicate a task to those cores (e.g., via taskset).
If you look at the current kernel arguments via “cat /proc/cmdline”, then you’ll see the current isolcpus lists those processors (they are zero based index, so the first core is CPU0, and 1-2 are the two Denver cores you see), and this disables them from being scheduled by “random” tasks. Thus “taskset”. Kernel command line parameters usually take the last argument (when there are multiple copies of the same argument) as the one to use. Thus, if you specify isolcpus=, then the last argument clears the blocking of CPU cores 1-2. You can add this to to the end of the “/boot/extlinux/extlinux.conf” “APPEND” key/value pair (if you have security fuses burned and use entirely partition based specifications, then you’d need to add this via the device tree’s “chosen->bootargs” parameter, but I discourage using the device tree for this unless it is mandatory).
There is a man page for taskset here if you want to use that:
https://man7.org/linux/man-pages/man1/taskset.1.html
Here are some related URLs from kernel.org and others which might provide a bit more insight:
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cpusets.html
https://www.kernel.org/doc/Documentation/kernel-per-CPU-kthreads.txt
https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/taskset
An example of binding an application to CPU2 (the second Denver core) from user space (likely you need sudo):
taskset 0x2 <_USER_APPLICATION_> &