Switch to 64bit kernel+OS environment (x86_64, aarch64)

Is your feature request related to a problem? Please describe. The following kernel output (catched on a vmWare ESXi used OVA RaspberryMatic) should explain it all:

[    0.051050] ************************************************************
[    0.051050] ** WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!  **
[    0.051051] **                                                        **
[    0.051051] ** You are using 32-bit PTI on a 64-bit PCID-capable CPU. **
[    0.051051] ** Your performance will increase dramatically if you     **
[    0.051051] ** switch to a 64-bit kernel!                             **
[    0.051052] **                                                        **
[    0.051052] ** WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!  **
[    0.051052] ************************************************************

Thus, aside from the not-so-important point that with a 64bit native kernel+OS we could address more than 4GB RAM per application (barely required with RaspberryMatic, of course), we would perhaps benefit a lot with a 64bit native kernel+OS. In addition, some CCU Addons like RedMatic (https://github.com/rdmtc/RedMatic) are partly (on x86) only possible if a 64bit OS is used (see https://github.com/rdmtc/RedMatic/issues/374). So there are some good points to why a switch to a 64bit kernel+OS would perfectly sense (if this is easily possible, of course).

Describe the solution you’d like Due to the point that the eQ3 distributed binaries in the OCCU environment (https://github.com/eq-3/occu) are distributed as 32bit applications, as well as some CCU addons also still require a 32bit OS the following 3 step transition procedure is suggested:

• (1) Develop a multilib buildroot environment so that we will have a 64bit kernel + OS but provide the possibility to also still use 32bit applications. While this is unfortunately not natively possible with buildroot, there had been already some work in the multlib branch of RaspberryMatic (see https://github.com/jens-maus/RaspberryMatic/tree/multilib). This branch should be first finalized for the x86 target (already in alpha state!) and then ported over to ARM64 at a later state so that even a RaspberryPi3 or RaspberryPi4 could benefit from running a 64bit kernel+OS.
• (2) After having such a multlib version of RaspberryMatic released to the public (potentially still in 2020), we try to get eQ3 and others to move forward and port/distribute also 64bit versions of all majore CCU/OCCU components.
• (3) After most/all applications/ccu addons are available as 64bit native apps we could consider dropping 32bit support alltogether at some state (e.g. >2022) or consider keeping it for another while or even forever?!? But this could mean an additional overhead to still maintain the 32bit multlib compatibility in future.

Caveats Due to using 32bit-only CPUs, the tinkerboard and rpi0 target won’t benefit from it. In addition, we will have to add a new “rpi2” target because the RaspberryPi2 (except from the latest 1.2 revision) is also shipped with a 32bit-only CPU and thus won’t be able to benefit. Nevertheless, there should not be any limitations in still maintaining the rpi0, rpi2 and tinkerboard targets as 32bit only versions and only ship the OVA (x86) and rpi3, rpi4 target versions as full fledged 64bit OS versions.

Additional context The following list should be a working list of applications and addons/components which are currently limited to a 32bit OS environment and for which we might have to get ported to be running more smoothly in a 64bit OS so that point 3 could be fulfilled at some point in future (checked elements are already distributed or had been tested with 64bit compatibility):

OCCU:

• rfd
• hs485d
• hs485dLoader
• multimacd
• eq3configcmd
• SetInterfaceClock
• crypttool
• libhsscomm.so
• libeq3config.so
• libUnifiedLanComm.so
• libLanDeviceUtils.so
• tclsh
• libtcl8.2.so
• tclrega.so
• tclrpc.so
• tclticks.so (obsolete)
• hss_led
• eq3configd
• libelvutils.so
• ReGaHss
• libXmlRpc.so
• libxmlparser.so
• ssdpd
• eq3_char_loop kernel driver
• HMIPServer.jar (only aarch64 libNRJavaSerialv8.so missing, see https://github.com/jens-maus/RaspberryMatic/issues/903#issuecomment-706662901)
• hmip-copro-update.jar

Third-Party OS components:

• generic_raw_uart kernel driver
• detect_radio_module

CCU-Addons (with 32bit/64bit binary dependencies):

• RedMatic => (v7.1.1+ with 64bit/x86_64 binaries for OVA, ARM still armhf/32bit only)
• CUxd
• Mosquitto
• Redis

[jens-maus]

Here some development updates on the current state of affairs regarding development on the multilib 64bit OS works:

1. The multilib OS environments for the x86_64 targets (ova, intelnuc) seem to work flawlessly now. That means the bootloader and OS are ported to 64bit and the 32bit multilib environment (/lib32 vs /lib64) seem to work so that 64bit apps and 32bit apps can perfectly coexist and run within the 64bit RaspberryMatic. Only tests with a x86_64 version of RedMatic are missing and then these targets should be ready for a wider test audience.
2. The first ARM-based aarch64 target (rpi4) is ported to 64bit as well. However there are currently still some issues that need to be resolved separately:
   1. The HMIPServer.jar Java app only comes with a armhf (32bit) binary of the libNRJavaSerial.so library which is used to communicate with the rf module. A workaround has been integrated (https://github.com/jens-maus/RaspberryMatic/commit/b1133ad8cfe27c8dff7a33c004854836cb3ac74d#diff-f63cfb2bb642b7b0ce5840def4fba072) but for a permanent solution eQ3 has to update their libNRJavaSerial dependency to the latest version which comes with a ARM64 (aarch64) version of this library.
   2. Due to sone unknown reasons some armhf 32bit binaries shipped with OCCU for ARM do not seem to work properly in the new multilib environment and, e.g. multimacd, rfd and ReGHss exit with a `Illegal instruction’ error or do not work properly at all. Interestingly, when using the CCU3 native armhf binaries instead of the supplied ones from OCCU, these binaries work and the whole multilib systems boots up fine and works. Thus, more investigations required to identify the root cause and to potentially use a different cross compiler or setting to get these binaries running fine in the multilib environment. or we directöy switch to aarch64 compilation as explained in step 2 above. (fixed by c42bcb2)

[angelnu]

The option is --enable-ino32 which is then used for the fuse program that the gluster client uses natively:

/usr/sbin/glusterfs --enable-ino32 --log-level=ERROR --log-file=/var/snap/microk8s/common/var/lib/kubelet/plugins/kubernetes.io/glusterfs/raspberrymatic-clusterfs/raspberrymatic-0-glusterfs.log --fuse-mountopts=auto_unmount --process-name fuse --volfile-server=192.168.2.86 --volfile-server=192.168.2.84 --volfile-server=192.168.2.86 --volfile-server=192.168.2.87 --volfile-id=ccu --fuse-mountopts=auto_unmount /var/snap/microk8s/common/var/lib/kubelet/pods/fd7f1a57-2be0-46da-bc5e-26d450b3861b/volumes/kubernetes.io~glusterfs/raspberrymatic-clusterfs

Unfortunately the logs did not show anything but I have to admit I focused in the rfd daemon. The error manifested by the homematic devices dissapearing from the UI after a few minutes of restoring a backup. After this the HMIP devices still worked. My test might be biased since I have way more Homematic devices than Homematic IP.

I will try to increase the log level of Rega, dissable my circumvention and see if I can get any additional logs showing the error. I could also run with strace and see if I detect any syscal queering the inode. If you have an< other suggestion on what debug data to collect please let me know - it will have to wait likely until I get time over the weekend.