search

armbian / build

Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf
https://www.armbian.com
GNU General Public License v2.0
4.24k stars 2.32k forks source link

scripts/module.lds needs to be packaged in sunxi edge kernel headers >5.10 #3103

Closed lampra1 closed 3 years ago

lampra1 commented 3 years ago

Describe the bug scripts/module.lds needs to be packaged in sunxi edge kernels headers (sunxi current on buster is fine)

To Reproduce Steps to reproduce the behavior: download or compile and Install sunxi edge kernel headers and list the contents of the scripts dir

Provide logs: https://pastebin.com/ze0H8XVJ

igorpecovnik commented 3 years ago

Known, but no time. https://armbian.atlassian.net/browse/AR-828

igorpecovnik commented 3 years ago

@The-going any idea how to fix this? Is this a problem of our packaging scripts?

lampra1 commented 3 years ago

For reference https://github.com/torvalds/linux/commit/596b0474d3d9

The-going commented 3 years ago

@The-going any idea how to fix this? Is this a problem of our packaging scripts?

@igorpecovnik , It looks like my unfinished work. The forum member armbian Cornelius warned about this here.

@lampra1, You are the second person from whom I hear about this. Please tell us about how you use this package (build a kernel module on the board or something else). This will help me to test the package correctly after making changes.

lampra1 commented 3 years ago

@The-going, I was trying to build this for kernel 5.13 (edge) on sunxi64 (orangepizero2) natively as the Device Tree overlays are not yet available for this board. When trying to build with dkms after digging through the errors, I stumbled upon missing module.lds in the scripts folder. Googling around, some people suggested that module.lds.S renaming would suffice for kernel 5.10, but this was not the case for kernel 5.13

The-going commented 3 years ago

I was trying to build this for kernel 5.13 (edge) on sunxi64 (orangepizero2) natively

@lampra1 Good. I will now make corrections and check on this example. But, excuse my curiosity, what requirements do you want to use a single-wire line? I mean the response time\delay, the transfer rate.

pyavitz commented 3 years ago

As suggested this can be easily remedied, as I've been been doing it since 5.10.y.

My current packaging bit:

cp headers-byteshift.patch $destdir/
if [ -e $destdir/scripts/module.lds ];
    then install -m 0644 $srctree/scripts/module.lds $destdir/ > /dev/null 2>&1;
fi
    mkdir -p $kernel_headers_dir/DEBIAN
    cat > $kernel_headers_dir/DEBIAN/postinst <<EOT
#!/bin/bash
# compile headers
clean_headers(){
echo 'y' | make M=scripts clean
if [ -e headers-byteshift.patch ]; then patch -p1 < headers-byteshift.patch; fi
if [ -e module.lds ]; then install -m 0644 module.lds scripts/; fi
rm -f {headers-byteshift.patch,module.lds}
}

set -e
cd /usr/src/linux-headers-$version
echo -e "\e[1;37mCompiling headers\e[0m ..."
find -type f -exec touch {} +
clean_headers > /dev/null 2>&1
echo 'y' | make -j\$(grep -c 'processor' /proc/cpuinfo) -s scripts >/dev/null
echo 'y' | make -j\$(grep -c 'processor' /proc/cpuinfo) -s M=scripts/mod/ >/dev/null
exit 0
EOT

    chmod 755 $kernel_headers_dir/DEBIAN/postinst

The basics of what I did, is I no longer patch and clean during kernel compilation. Instead I leave the headers-byteshift.patch and copy/install the .lds in the root of the linux headers directory. I then clean, patch and reinstall the original .lds before compiling the headers. This corrects the problem of the missing file, as make clean now removes it.

As most of my patching is based on Armbians work, I'm sure this wouldn't be a huge effort to change on your end.

The-going commented 3 years ago

My current packaging bit:

Thank you, but there is a more beautiful solution. The file is deleted if the cleanup is performed in the postinst script. For kernel 5.13, cleaning after cross-compilation does not delete the file.

pyavitz commented 3 years ago

My current packaging bit:

Thank you, but there is a more beautiful solution. The file is deleted if the cleanup is performed in the postinst script. For kernel 5.13, cleaning after cross-compilation does not delete the file.

Good to know, I never tried as it was consistent after 5.10 in my testing. Either way, keeping a copy of the file and putting it back after the clean seems to me to be an easy solution. Good luck.

The-going commented 3 years ago

Good to know, I never tried as it was consistent after 5.10 in my testing.

Since version 5.12, there are no collisions
with deleting the scripts/module.lds file.

This pathology begins with 5.10 and ends on 5.11 inclusive,
and this is due to internal migration in the core.
The-going commented 3 years ago

Move the cleanup of the scripts target from the postinst script to the logically correct place so that the cleanup occurs with the same arguments of the make command and the same compiler.

The-going commented 3 years ago

The linux-headers package must be built in the last queue

pyavitz commented 3 years ago

Move the cleanup of the scripts target from the postinst script to the logically correct place so that the cleanup occurs with the same arguments of the make command and the same compiler.

In my experience that makes zero difference unless were compiling, armv6 or armv7 on armv8? In that case one would need to make ARCH=arm, but when doing cross on x86-64 it doesn't seem to matter. If that is what you are referring too?

As for cross vs native you could make it so the kernel script is only created if need be and the module.lds file is only replaced if removed.

if [ -e headers-byteshift.patch ]; then
    cp headers-byteshift.patch $destdir/
    cp $srctree/scripts/module.lds $destdir/
    mkdir -p $kernel_headers_dir/DEBIAN
    cat > $kernel_headers_dir/DEBIAN/postinst <<EOT
#!/bin/bash
# compile headers

set -e

clean_headers(){
find -type f -exec touch {} +
echo 'y' | make M=scripts clean
patch -p1 < headers-byteshift.patch
if [ -e scripts/module.lds ]; then :; else install -m 0644 module.lds scripts/; fi
rm -f {headers-byteshift.patch,module.lds}
echo 'y' | make -j\$(grep -c 'processor' /proc/cpuinfo) -s scripts
echo 'y' | make -j\$(grep -c 'processor' /proc/cpuinfo) -s M=scripts/mod/
}

cd /usr/src/linux-headers-$version
echo -e "\e[1;37mCompiling headers\e[0m ..."
clean_headers > /dev/null 2>&1;
exit 0
EOT
    chmod 755 $kernel_headers_dir/DEBIAN/postinst
fi

I would think most people aren't using aarch64 to cross compile armv6 and armv7, so its kind of no go argument. That is more of niche case, but one I have accounted for in other build situations.

The-going commented 3 years ago

If cleaning is done in the script after installing the package, then the file is deleted and manipulations with saving and restoring are required. In any case, this is a temporary phenomenon for kernels 5.10-5.11

Check out the latest changes here and you'll see what I'm doing.

The-going commented 3 years ago

@lampra1 The kernel module is being assembled. I have not checked the functionality of the module.

leo@orangepipc2:~/w1-gpio-cl$ uname -r
5.13.13-sunxi64
leo@orangepipc2:~/w1-gpio-cl$ ls /lib/modules/
5.13.13-sunxi64
leo@orangepipc2:~/w1-gpio-cl$ ls /usr/src
linux-headers-5.13.13-sunxi64
leo@orangepipc2:~/w1-gpio-cl$ KERNEL_SRC='/usr/src/linux-headers-5.13.13-sunxi64' make
NOTE: w1 -> /usr/src/linux-headers-5.13.13-sunxi64/include/linux
NOTE: gen-mast.h was generated
make -C /usr/src/linux-headers-5.13.13-sunxi64 M=/home/leo/w1-gpio-cl modules
make[1]: Entering directory '/usr/src/linux-headers-5.13.13-sunxi64'
  CC [M]  /home/leo/w1-gpio-cl/w1-gpio-cl.o
  MODPOST /home/leo/w1-gpio-cl/Module.symvers
  CC [M]  /home/leo/w1-gpio-cl/w1-gpio-cl.mod.o
  LD [M]  /home/leo/w1-gpio-cl/w1-gpio-cl.ko
make[1]: Leaving directory '/usr/src/linux-headers-5.13.13-sunxi64'
leo@orangepipc2:~/w1-gpio-cl$ sudo make install
install -m644 w1-gpio-cl.ko /lib/modules/`uname -r`/kernel/drivers/w1/masters
depmod
leo@orangepipc2:~/w1-gpio-cl$ sudo modinfo w1-gpio-cl
filename:       /lib/modules/5.13.13-sunxi64/kernel/drivers/w1/masters/w1-gpio-cl.ko
author:         Piotr Stolarz <pstolarz@o2.pl>
description:    Command line configured gpio w1 bus master driver
license:        GPL
version:        1.2.1
srcversion:     A04B0964588181954FF44B0
depends:        wire
name:           w1_gpio_cl
vermagic:       5.13.13-sunxi64 SMP mod_unload aarch64
parm:           m1:1st w1 bus master specification (charp)
parm:           m2:2nd w1 bus master specification (charp)
parm:           m3:3rd w1 bus master specification (charp)
parm:           m4:4th w1 bus master specification (charp)
parm:           m5:5th w1 bus master specification (charp)
leo@orangepipc2:~/w1-gpio-cl$ ls /lib/modules/`uname -r`/kernel/drivers/w1/masters
ds1wm.ko  ds2482.ko  ds2490.ko  sgi_w1.ko  w1-gpio-cl.ko  w1-gpio.ko

leo@orangepipc2:~/w1-gpio-cl$ sudo modprobe w1-gpio
leo@orangepipc2:~/w1-gpio-cl$ lsmod | grep gpio
w1_gpio                16384  0
wire                   40960  1 w1_gpio
lampra1 commented 3 years ago

@The-going Thank you. I will test as soon as your pr is merged. Regarding requirements for the single-wire line, no idea! Just trying to set up an 1wire thermal sensor.

The-going commented 3 years ago

kernel 5.13 (edge) on sunxi64 (orangepizero2)

@lampra1 I have started the build for your board. 30 minutes and there will be a download link. Make a test assembly of the module before the PR is accepted.

The-going commented 3 years ago

https://github.com/The-going/PKG_test

lampra1 commented 3 years ago

@The-going Seems to be working fine. I will also try with dkms later 

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# ll
total 72
drwxr-xr-x 3 root   root    4096 Ιουν 24 17:24 ./
drwxrwxr-x 4 lampra lampra  4096 Σεπ   6 18:24 ../
-rw-r--r-- 1 root   root     173 Ιουν 24 17:24 dkms.conf
-rw-r--r-- 1 root   root     118 Ιουν 24 17:24 .gitignore
-rw-r--r-- 1 root   root   18011 Ιουν 24 17:24 LICENSE
-rw-r--r-- 1 root   root    3165 Ιουν 24 17:24 Makefile
-rw-r--r-- 1 root   root    9238 Ιουν 24 17:24 README.md
drwxr-xr-x 2 root   root    4096 Ιουν 24 17:24 schema/
-rw-r--r-- 1 root   root   13455 Ιουν 24 17:24 w1-gpio-cl.c

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# uname -r
5.13.14-sunxi64

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# ls /lib/modules/
5.13.11-sunxi64  5.13.14-sunxi64

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# ls /usr/src
linux-headers-5.13.11-sunxi64  linux-headers-5.13.14-sunxi64  w1-gpio-cl-1.2.1
root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# KERNEL_SRC='/usr/src/linux-headers-5.13.14-sunxi64' make
NOTE: w1 -> /usr/src/linux-headers-5.13.14-sunxi64/include/linux
NOTE: gen-mast.h was generated
make -C /usr/src/linux-headers-5.13.14-sunxi64 M=/home/lampra/Downloads/w1-gpio-cl-master modules
make[1]: Entering directory '/usr/src/linux-headers-5.13.14-sunxi64'
  CC [M]  /home/lampra/Downloads/w1-gpio-cl-master/w1-gpio-cl.o
  MODPOST /home/lampra/Downloads/w1-gpio-cl-master/Module.symvers
  CC [M]  /home/lampra/Downloads/w1-gpio-cl-master/w1-gpio-cl.mod.o
  LD [M]  /home/lampra/Downloads/w1-gpio-cl-master/w1-gpio-cl.ko
make[1]: Leaving directory '/usr/src/linux-headers-5.13.14-sunxi64'

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# make install
install -m644 w1-gpio-cl.ko /lib/modules/`uname -r`/kernel/drivers/w1/masters
depmod

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# sudo modinfo w1-gpio-cl
filename:       /lib/modules/5.13.14-sunxi64/kernel/drivers/w1/masters/w1-gpio-cl.ko
author:         Piotr Stolarz <pstolarz@o2.pl>
description:    Command line configured gpio w1 bus master driver
license:        GPL
version:        1.2.1
srcversion:     A04B0964588181954FF44B0
depends:        wire
name:           w1_gpio_cl
vermagic:       5.13.14-sunxi64 SMP mod_unload aarch64
parm:           m1:1st w1 bus master specification (charp)
parm:           m2:2nd w1 bus master specification (charp)
parm:           m3:3rd w1 bus master specification (charp)
parm:           m4:4th w1 bus master specification (charp)
parm:           m5:5th w1 bus master specification (charp)

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# ls /lib/modules/`uname -r`/kernel/drivers/w1/masters
ds1wm.ko  ds2482.ko  ds2490.ko  sgi_w1.ko  w1-gpio-cl.ko  w1-gpio.ko

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# modprobe w1-gpio

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# lsmod | grep gpio
w1_gpio                16384  0
wire                   40960  1 w1_gpio

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# rmmod w1-gpio
root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# modprobe w1-gpio-cl m1="gdt:73"
root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# lsmod | grep gpio
w1_gpio_cl             16384  0
wire                   40960  2 w1_therm,w1_gpio_cl
root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# ls /sys/bus/w1/devices
28-01192e252edf  w1_bus_master1
root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
 gpio-73  (                    |w1-gpio-cl          ) in  hi 
 gpio-76  (                    |red:power           ) out hi 
 gpio-77  (                    |green:status        ) out lo 
 gpio-80  (                    |usb1-vbus           ) out hi 
 gpio-166 (                    |cd                  ) in  lo IRQ ACTIVE LOW

gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl:

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# cat /sys/devices/w1_bus_master1/28-01192e252edf/
alarms       driver/      ext_power    hwmon/       name         resolution   temperature  w1_slave     
conv_time    eeprom_cmd   features     id           power/       subsystem/   uevent       

root@orangepizero2:/home/lampra/Downloads/w1-gpio-cl-master# cat /sys/devices/w1_bus_master1/28-01192e252edf/w1_slave 
9f 01 4b 46 7f ff 0c 10 c9 : crc=c9 YES
9f 01 4b 46 7f ff 0c 10 c9 t=25937
lampra1 commented 3 years ago

Building also seems good with dkms

sudo dkms install w1-gpio-cl/1.2.1

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j4 KERNELRELEASE=5.13.14-sunxi64......
cleaning build area...

DKMS: build completed.

w1-gpio-cl.ko:
Running module version sanity check.

Good news! Module version 1.2.1 for w1-gpio-cl.ko
exactly matches what is already found in kernel 5.13.14-sunxi64.
DKMS will not replace this module.
You may override by specifying --force.

depmod.....

DKMS: install completed.
The-going commented 3 years ago

Good! In this version, the module is created but it is not signed.

dmesg
....
[12019.436782] w1_gpio_cl: module verification failed: signature and/or required key missing - tainting kernel
....

$ modinfo w1-gpio-cl
filename:       /lib/modules/5.13.13-sunxi64/kernel/drivers/w1/masters/w1-gpio-cl.ko
author:         Piotr Stolarz <pstolarz@o2.pl>
description:    Command line configured gpio w1 bus master driver
license:        GPL
version:        1.2.1
srcversion:     A04B0964588181954FF44B0
depends:        wire
name:           w1_gpio_cl
vermagic:       5.13.13-sunxi64 SMP mod_unload aarch64
parm:           m1:1st w1 bus master specification (charp)
parm:           m2:2nd w1 bus master specification (charp)
parm:           m3:3rd w1 bus master specification (charp)
parm:           m4:4th w1 bus master specification (charp)
parm:           m5:5th w1 bus master specification (charp)

As an example, an internal module:

$ modinfo w1-gpio
filename:       /lib/modules/5.13.13-sunxi64/kernel/drivers/w1/masters/w1-gpio.ko
license:        GPL
author:         Ville Syrjala <syrjala@sci.fi>
description:    GPIO w1 bus master driver
alias:          of:N*T*Cw1-gpioC*
alias:          of:N*T*Cw1-gpio
depends:        wire
intree:         Y
name:           w1_gpio
vermagic:       5.13.13-sunxi64 SMP mod_unload aarch64
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        21:45:42:9A:EF:1F:3C:CC:33:C2:77:F6:3A:5C:F9:D1:CE:52:AA:E3
sig_hashalgo:   sha1
signature:      0A:D1:61:3F:4D:48:95:D3:41:F7:FE:1D:64:37:AA:68:8E:65:02:6A:
                29:1E:E0:68:EC:5A:7E:67:C7:C6:BA:6C:BF:54:0D:09:37:31:2B:48:
                E8:7A:22:8C:8E:27:7A:63:24:9C:EF:C3:FD:D3:4B:08:48:8E:E8:EA:
                26:35:DB:F1:2D:44:9F:F6:2C:40:32:52:50:FF:E4:E6:A2:73:6A:BA:
                EA:68:4D:9F:58:F5:05:04:52:00:3D:3A:D4:D7:BE:A4:E4:84:19:9E:
                CD:97:03:7A:F6:47:88:DC:6F:63:88:A2:F1:73:92:96:A2:CE:32:9B:
                E9:13:9A:C1:ED:5B:18:58:9F:72:72:3D:15:6C:7A:0E:25:9D:30:68:
                9E:A9:4D:2E:8E:9C:D7:A5:95:B5:00:2A:01:6C:2D:23:A2:ED:8B:82:
                49:39:72:E4:DE:90:B8:AB:98:DA:25:C9:02:F8:A2:EE:36:30:95:07:
                A7:1C:14:2B:EC:DF:DB:39:42:12:49:E5:A3:7C:E5:DA:0D:60:D1:1B:
                3E:DE:27:93:38:65:5A:81:DE:AE:94:46:1D:D8:91:90:9E:69:B6:32:
                E8:22:5D:80:B4:F1:1E:89:5D:C4:BF:58:0D:F3:74:80:2B:AE:56:08:
                17:EF:BE:C9:8E:77:59:0E:A6:24:09:18:CE:A0:76:5A:9E:60:89:58:
                DF:F6:D3:16:9D:DA:61:AC:15:1C:E6:92:67:16:04:B0:51:BA:AF:D6:
                46:BE:78:49:03:5C:A4:4E:C9:4F:D2:41:41:DD:84:12:63:BA:37:2C:
                2D:42:FA:E7:DB:8A:02:86:41:DB:EB:B0:AD:CD:40:6D:ED:39:9D:CC:
                82:D2:2C:24:9A:5E:D2:E2:E5:19:35:27:9D:44:31:EB:AA:69:39:7A:
                75:0A:5A:30:D0:93:17:CC:C8:F1:7C:DD:6B:BD:60:72:DC:50:6D:A2:
                A8:9A:8F:EE:89:4B:EB:06:ED:55:A9:84:5E:7C:02:D1:FA:1F:77:03:
                EC:B5:76:5D:E0:90:14:39:98:56:40:83:69:D9:4C:7B:C0:30:BC:92:
                00:BB:C3:D3:B3:92:0C:60:DD:25:5E:B4:4C:D1:EB:99:51:D2:43:98:
                D9:99:C1:64:7D:43:CB:9D:B0:9C:2F:1C:BF:EB:FB:E3:11:9A:8F:DE:
                5A:C4:44:81:19:2C:6E:9C:AA:F7:1B:0B:DD:A2:E7:E1:CB:7A:59:5F:
                08:3D:3F:31:9E:8D:B3:86:04:1D:48:5D:74:1C:77:30:23:85:93:A8:
                78:B8:BC:90:10:F5:BD:C4:9C:72:83:D3:81:17:BD:47:14:AC:16:A9:
                C9:AD:AA:24:F4:91:1E:24:F5:F8:87:53
The-going commented 3 years ago

@igorpecovnik @pyavitz Question! Do external modules need to be signed?

The-going commented 3 years ago

DKMS: install completed.

@lampra1 Thank you for the GPIO test. It was informative.

igorpecovnik commented 3 years ago

Do external modules need to be signed?

Not a show stopper for us, but we could do this in a separate task. Once.

The-going commented 3 years ago

Do external modules need to be signed?

Not a show stopper for us, but we could do this in a separate task. Once.

Good. I need to study the issue. PR is done

igorpecovnik commented 3 years ago

Thank you @lampra1 for assistance and testings.