After apt upgrade my 32 Bit OS runs on a 64 bit kernel and now I can't compile an external module.

[nikal]

Hi,

a couple hours ago I did the routine apt update/upgrade to my RPi4 which runs some services in my home along with an AP based on a TP-Link usb adapter which uses a external driver from here

Code: Select all

 https://github.com/ivanovborislav/rtl88x2bu 

After the upgrade which included a new kernel I ended up running on a 64 bit kernel on my 32 bit OS.

The problem is that the headers of the new kernel couldn't be found under build directory because it didn't exist at all under/lib/modules/6.1.19-v8+/

Looking under /usr/src/ I wasn't able to find the 64 bit headers anywhere. The directories under /usr/src are the following:

Code: Select all

drwxr-xr-x 26 root root 4096 Mar 19 01:18 linux-headers-6.1.19+
drwxr-xr-x 25 root root 4096 Mar 19 00:32 linux-headers-6.1.19-v7+
drwxr-xr-x 25 root root 4096 Mar 19 00:32 linux-headers-6.1.19-v7l+

I tried to make a soft link to missing build directory to any of them and although module can be compiled successfully it can't be loaded apparently because it's the wrong executable format.

Code: Select all

Invalid architecture in ELF header: 40 

I have DKMS installed but I don't use it and I don't think it will work anyway because 64 bit headers are probably not installed in my system and this is weird.

I need your help!

Thanks in advance

[cleverca22]

when using a 32bit userland on raspi-os, you can freely switch between 32bit and 64bit kernels with arm_64bit=1 in config.txt

if you remove arm_64bit=1, then it should revert back to the 32bit kernel

[nikal]

when using a 32bit userland on raspi-os, you can freely switch between 32bit and 64bit kernels with arm_64bit=1 in config.txt

if you remove arm_64bit=1, then it should revert back to the 32bit kernel

Hi,

that's the problem. I never had arm_64bit=1 in my config.txt that's why I'm scratching my head with my shinny new 64 bit kernel.

Any way to go back to the 5.15 and get the headers as well ?

[cleverca22]

what are the contents of /boot and config.txt?

[nikal]

what are the contents of /boot and config.txt?

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1800
arm_freq_min=800
initial_turbo=40

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=off

# Automatically load overlays for detected cameras
#camera_auto_detect=1

# Automatically load overlays for detected DSI displays
#display_auto_detect=1

# Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d
#max_framebuffers=2

# Disable compensation for displays with overscan
disable_overscan=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

[pi4]
dtoverlay=argonone,hysteresis=3

# Run as fast as firmware / board allows
arm_boost=1

[all]
# Disable WiFi/BT
dtoverlay=disable-wifi
dtoverlay=disable-bt
# disable Activity LED
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off
# turn off Mainboard LEDs
dtoverlay=act-led

and the contents of my /boot dir

Code: Select all

-rwxr-xr-x  1 root root   28111 Mar 19 01:42  bcm2708-rpi-b.dtb
-rwxr-xr-x  1 root root   28418 Mar 19 01:42  bcm2708-rpi-b-plus.dtb
-rwxr-xr-x  1 root root   27790 Mar 19 01:42  bcm2708-rpi-b-rev1.dtb
-rwxr-xr-x  1 root root   28032 Mar 19 01:42  bcm2708-rpi-cm.dtb
-rwxr-xr-x  1 root root   27856 Mar 19 01:42  bcm2708-rpi-zero.dtb
-rwxr-xr-x  1 root root   29267 Mar 19 01:42  bcm2708-rpi-zero-w.dtb
-rwxr-xr-x  1 root root   29305 Mar 19 01:42  bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root root   29304 Mar 19 01:42  bcm2709-rpi-cm2.dtb
-rwxr-xr-x  1 root root   30170 Mar 19 01:42  bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root root   31922 Mar 19 01:42  bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root root   32533 Mar 19 01:42  bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root root   30157 Mar 19 01:42  bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root root   31230 Mar 19 01:42  bcm2710-rpi-zero-2.dtb
-rwxr-xr-x  1 root root   31230 Mar 19 01:42  bcm2710-rpi-zero-2-w.dtb
-rwxr-xr-x  1 root root   52556 Mar 19 01:42  bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root root   52424 Mar 19 01:42  bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root root   53165 Mar 19 01:42  bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root root   38182 Mar 18 20:34  bcm2711-rpi-cm4-io.dtb
-rwxr-xr-x  1 root root   50447 Mar 19 01:42  bcm2711-rpi-cm4s.dtb
-rwxr-xr-x  1 root root   52476 Mar 19 01:42  bootcode.bin
-rwxr-xr-x  1 root root     154 Nov  9 15:55  cmdline.txt
-rwxr-xr-x  1 root root    2335 Sep 22 20:37  config.txt
-rwxr-xr-x  1 root root   18693 Mar 18 20:34  COPYING.linux
-rwxr-xr-x  1 root root      41 Mar 19 01:42  .firmware_revision
-rwxr-xr-x  1 root root    3170 Mar 19 01:42  fixup4cd.dat
-rwxr-xr-x  1 root root    5398 Mar 19 01:42  fixup4.dat
-rwxr-xr-x  1 root root    8384 Mar 19 01:42  fixup4db.dat
-rwxr-xr-x  1 root root    8386 Mar 19 01:42  fixup4x.dat
-rwxr-xr-x  1 root root    3170 Mar 19 01:42  fixup_cd.dat
-rwxr-xr-x  1 root root    7265 Mar 19 01:42  fixup.dat
-rwxr-xr-x  1 root root   10229 Mar 19 01:42  fixup_db.dat
-rwxr-xr-x  1 root root   10227 Mar 19 01:42  fixup_x.dat
-rwxr-xr-x  1 root root     145 Jan 28  2022  issue.txt
-rwxr-xr-x  1 root root 6649408 Mar 19 01:42  kernel7.img
-rwxr-xr-x  1 root root 7063616 Mar 19 01:42  kernel7l.img
-rwxr-xr-x  1 root root 8158124 Mar 19 01:42  kernel8.img
-rwxr-xr-x  1 root root 6289552 Mar 19 01:42  kernel.img
-rwxr-xr-x  1 root root    1594 Mar 18 20:34  LICENCE.broadcom
drwxr-xr-x  2 root root   24576 Mar 18 20:34  overlays
-rwxr-xr-x  1 root root  805436 Mar 19 01:42  start4cd.elf
-rwxr-xr-x  1 root root 3747272 Mar 19 01:42  start4db.elf
-rwxr-xr-x  1 root root 2250848 Mar 19 01:42  start4.elf
-rwxr-xr-x  1 root root 2998344 Mar 19 01:42  start4x.elf
-rwxr-xr-x  1 root root  805436 Mar 19 01:42  start_cd.elf
-rwxr-xr-x  1 root root 4819144 Mar 19 01:42  start_db.elf
-rwxr-xr-x  1 root root 2975104 Mar 19 01:42  start.elf
-rwxr-xr-x  1 root root 3722024 Mar 19 01:42  start_x.elf
-rwxr-xr-x  1 root root   10745 Nov 20  2021  usb-boot.zip

[trejan]

Add arm_64bit=0 to config.txt

The Pi 4/400 firmware now prefers the 64-bit kernel if one exists. Setting arm_64bit=0 forces it to use the 32-bit kernel.

[nikal]

Add arm_64bit=0 to config.txt

The Pi 4/400 firmware now prefers the 64-bit kernel if one exists. Setting arm_64bit=0 forces it to use the 32-bit kernel.

Thanks for the reply. Problem solved (I didn't know that this switch worked the other way around).

In any case, is there any way to compile this module for the 64 bit kernel ? Why in the first place the 64 bit headers never installed in my system ?

Thanks in advance for your help!

[cleverca22]

In any case, is there any way to compile this module for the 64 bit kernel ?

to start with, you would need a cross-compiler that can target aarch64

[PhilE]

See here for instructions: viewtopic.php?t=344246&start=275#p2091356

[nikal]

See here for instructions: viewtopic.php?t=344246&start=275#p2091356

Hi!

thanks for reply and the link.

I tried to (cross)compile the module following your instructions (I just used the environment variables, didn't touch the Makefile) and the result was this

Code: Select all

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C /lib/modules/6.1.19-v7l+/build M=/root/rtl88x2bu  modules
make[1]: Entering directory '/usr/src/linux-headers-6.1.19-v7l+'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
  You are using:           aarch64-linux-gnu-gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
  CC [M]  /root/rtl88x2bu/core/rtw_cmd.o
  CC [M]  /root/rtl88x2bu/core/rtw_security.o
  CC [M]  /root/rtl88x2bu/core/rtw_debug.o
  CC [M]  /root/rtl88x2bu/core/rtw_io.o
In file included from ./include/linux/types.h:6,
                 from /root/rtl88x2bu/include/basic_types.h:75,
                 from /root/rtl88x2bu/include/drv_types.h:26,
                 from /root/rtl88x2bu/core/rtw_cmd.c:17:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
    5 | #include <asm/types.h>

I understand that something goes wrong with the kernel headers. It probably looks for the file in the wrong path. Should I boot in a 64 bit kernel to to make the compile ? I don't think it makes any difference since we are in a cross-compile environment.

I would appreciate any help

Thanks in advance.

[aBUGSworstnightmare]

You are aware that you're running legacy graphics driver with that config.txt?

[nikal]

You are aware that you're running legacy graphics driver with that config.txt?

Yep but I don't use the desktop on this raspi. It's a headless server. It's a very old installation that I have for several years starting from the first version of Raspi up to RPi4. I have done many upgrades and adjustments so I won't have to setup all the services again. It's a very stable and reliable server so far. I also use another 3 Raspis for various things like adding some "smartness" to a couple of UPS, another monitoring my home power consumption and so on.

[nikal]

I found a solution to my problem so I can now run a 64 bit kernel with my out of the tree wireless driver module compiled against the 6.1 branch of 64 bit kernel.

I set a Linux virtual machine in my desktop PC so I can use the power of my CPU for the compilation. Then I cloned the sources of the 6.1 kernel branch

Code: Select all

git clone --depth=1 https://github.com/raspberrypi/linux/tree/rpi-6.1.y

Then I set up a cross compiling environment based on the instructions here

https://www.raspberrypi.com/documentati ... the-kernel

I prepared the kernel source and compiled only the modules so to get the symver file.

Code: Select all

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- modules

I edited the out of the tree module Makefile and changed all the environment variables with fixed links to the paths where the kernel sources were located.

Finally I compiled successfully the module against the 6.1 kernel using the 64 bit toolchain and then copied everything back to raspberry pi 4.

There I changed the installation path for the module to match the version of the kernel and I installed and depmoded without problem.

Now my wireless adapter runs with a 64 bit kernel and driver.

However, I still can't understand why I had to do all these time consuming process. Before the last update of the kernel when everything was on 5.15 32 bit branch everything was just a recompile of the module every time a new kernel was installed. A matter of 5 minutes work.

I still can't find a logical explanation for the kernel sources and the errors during compilation. Why the cloned sources from the github worked while the deb package of the headers from official repo didn't.

[PhilE]

Cross-compiling modules is not a use case I had considered before Friday. Apart from the need to use a different toolchain, I don't believe that any of your module building problems will be difficult to overcome given a bit of time.

With arm_64bit=0, are you able to build and install your external module?

[nikal]

Cross-compiling modules is not a use case I had considered before Friday. Apart from the need to use a different toolchain, I don't believe that any of your module building problems will be difficult to overcome given a bit of time.

With arm_64bit=0, are you able to build and install your external module?

As I said earlier, yes, If I switch to 32 Bit kernel the module compilation is done without issues. The problem here is that my system has a 32 bit userland and never before after countless kernel updates all these years had to deal with a 64 bit kernel update without any warning or prior notice. I suppose this is an issue for other users as well.

Nevertheless, I prefer to use a 64 bit kernel if I can keep using the out of tree modules. I think that from version 6.2 the wifi adapter has native support by the kernel.

[PhilE]

If that's the case we can look at back-porting it into our 6.1 branch.

[nikal]

If that's the case we can look at back-porting it into our 6.1 branch.

That would be great. Actually I think that this driver has been included in the linux kernel since 5.2 but some distros choose not to include it by default. The drivers is called RTW88 (this chipset series has the prefix 88xx). So most users rely on the work of developers who keep patching and update the legacy realtek driver for newer kernels (currently there is support up to kernel 6.3)

[RonR]

The drivers is called RTW88 (this chipset series has the prefix 88xx).

The current source (6.1.y) appears to contain the RTW88 drivers but they're not being compiled by default and I'm not sure where to enable it:

/usr/src/linux/drivers/net/wireless/realtek/rtw88

[PhilE]

There are several config options that may be relevant:

Code: Select all

config RTW88_8822BE
	tristate "Realtek 8822BE PCI wireless network adapter"
	  Select this option will enable support for 8822BE chipset
	  802.11ac PCIe wireless network adapter

config RTW88_8822CE
	tristate "Realtek 8822CE PCI wireless network adapter"
	  Select this option will enable support for 8822CE chipset
	  802.11ac PCIe wireless network adapter

config RTW88_8723DE
	tristate "Realtek 8723DE PCI wireless network adapter"
	  Select this option will enable support for 8723DE chipset
	  802.11n PCIe wireless network adapter

config RTW88_8821CE
	tristate "Realtek 8821CE PCI wireless network adapter"
	  Select this option will enable support for 8821CE chipset
	  802.11ac PCIe wireless network adapter

config RTW88_DEBUG
	bool "Realtek rtw88 debug support"
	  Enable debug support
	  If unsure, say Y to simplify debug problems

config RTW88_DEBUGFS
	bool "Realtek rtw88 debugfs support"
	  Enable debug support
	  If unsure, say Y to simplify debug problems

[nikal]

The driver that I personally use is for a USB 3.0 adapter. The PCI adapters it's an uncommon case for raspberry pi (except maybe the CM that uses some extension board).

[nikal]

This is the driver that patches have been posted to enable USB support in the linux kernel.

https://github.com/ulli-kroll/rtw88-usb

[PhilE]

The relevant options and driver support appear with 6.2:

Code: Select all

config RTW88_8822BU
	tristate "Realtek 8822BU USB wireless network adapter"
	  Select this option will enable support for 8822BU chipset
	  802.11ac USB wireless network adapter

config RTW88_8822CU
	tristate "Realtek 8822CU USB wireless network adapter"
	  Select this option will enable support for 8822CU chipset
	  802.11ac USB wireless network adapter

config RTW88_8723DU
	tristate "Realtek 8723DU USB wireless network adapter"
	  Select this option will enable support for 8723DU chipset
	  802.11n USB wireless network adapter

config RTW88_8821CU
	tristate "Realtek 8821CU USB wireless network adapter"
	  Select this option will enable support for 8821CU chipset
	  802.11ac USB wireless network adapter

If I create a Pull Request against our 6.2 kernel, would you be prepared to test it? You'll just have to run a special rpi-update command to install it.
If that is successful I'll look at the backport.

[nikal]

If this is not destructive for my installation and I can easily get back to the current stable kernel, yes I will test it. I do have some experience with rpi-update and hashes and kernel compilation but as I said this is a home server with various services running and I'm a little bit cautious when I do experiments with it.

*Edited*

I do have a second RPi4 as a media player, I may use this one with a new SD card to test it.

[PhilE]

I honestly think this is a low risk test, the risk being that the 6.2 kernel doesn't support your use cases. The best protection is to clone your SD card, but short of that we can minimise the risk by installing the kernel to a different directory, with a config.txt check to switch between the two.

I'll report back when there's something to test.

[nikal]

I honestly think this is a low risk test, the risk being that the 6.2 kernel doesn't support your use cases. The best protection is to clone your SD card, but short of that we can minimise the risk by installing the kernel to a different directory, with a config.txt check to switch between the two.

I'll report back when there's something to test.

It's OK, I will manage it.