Raspberry Pi 4 doesn't auto-switch to 64bit mode based on kernel image filename

[agherzan]

Using the (current) latest firmware version (https://github.com/raspberrypi/firmware/releases/tag/1.20190709) I observed that in order to boot a 64bit kernel image I need to force the configuration using arm_64bit=1. The kernel image name (kernel8.img) seems to not be enough for the firmware to put the arm in 64bit mode even though this seems to be the expected behavior (raspberrypi/linux#3057 (comment)).

[Noltari]

This seems to be fixed with latest firmware.
arm_64bit=1 is no longer needed with kernel8.img.

[pelwell]

Correct. The firmware will still prefer the 32-bit kernel if present unless arm_64bit=1 is set, but if the only suitable kernel (based on the filename) is 64-bit then the correct stub and initialisation is used.

There are therefore now three ways to force 64-bit:

1. arm_64bit=1
2. kernel=kernel8.img.
3. Delete the compatible 32-bit kernels.

[agherzan]

Thanks for the heads up. I will be testing this and close the issue as soon as I validate.

[graysky2]

There are therefore now three ways to force 64-bit:
arm_64bit=1
kernel=kernel8.img.
Delete the compatible 32-bit kernels.

@pelwell - Are you certain about this? On my RPi4 running 64-bit kernel and userland, if I comment out the arm_64bit=1 line below, I don't even see the rainbow splash screen. The system is running the latest rpi-5.10.y kernel with the latest firmware. Here is my /boot/config.txt:

kernel=kernel8.img
arm_64bit=1
enable_gic=1

hdmi_force_hotplug=1

over_voltage=6
arm_freq=2000

[all]
include kodi.config.txt

With /boot/kodi.config.txt containing:

dtoverlay=vc4-kms-v3d,cma-384
dtoverlay=rpivid-v4l2
disable_overscan=1
disable_fw_kms_setup=1

[pelwell]

It almost works as advertised:

• Setting arm_64bit=1 forces 64-bit mode and will choose kernel8.img as the kernel file name but can be overridden using kernel=....
• Deleting (or renaming) the 32-bit kernels and leaving arm_64bit unset will cause kernel8.img to be loaded in 64-bit mode.
• What doesn't currently work is only forcing kernel=kernel8.img - the section of the loader code confuses user-specified kernel file with 32-bit kernel file, causing the "if we only have a 64-bit kernel and the user hasn't set arm_64bit=0 then force arm_64bit=1" test to fail.
• enable_gic=1 is set automatically if the DT specifies that the interrupt controller is an "arm,gic=400". The only reason to set it manually is for bare-metal, non-DT kernels.

If you are creating images that only include a 64-bit kernel then all you need to do is call your single kernel binary "kernel8.img" and leave kernel, arm-64bit and enable_gic unspecified.

I'll make a note to fix the only-kernel=kernel8.img case, but it isn't a priority.

[graysky2]

Thanks for the clarification. I removed the superfluous lines from /boot/config.txt and the the RPi4 booted as expected. To be clear, this is now my /boot/config.txt

hdmi_force_hotplug=1

over_voltage=6
arm_freq=2000

[all]
include kodi.config.txt

Aside from the successful boot, is there something I can inspect to insure full 64-bit behavior is detected and functional?

[pelwell]

The switch to 64-bit mode is an all or nothing thing - if it's executing your ARMv8 instructions then all is well - but you can use lscpu to confirm the processor details.

[graysky2]

Got it, thanks. The output of lscpu is identical whether I boot with the superfluous lines in /boot/config.txt or without them:

% lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     2000.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm crc32 cpuid