rpi-distro / firmware Goto Github PK

Describe the bug
raspberrypi-kernel-headers deb package is missing scripts/dtc/include-prefixes for building dtbo overlays, it should contain symbolic links just like in the linux kernel tree https://github.com/raspberrypi/linux/tree/rpi-6.1.y/scripts/dtc/include-prefixes

Without it, compiling .dtbo files of out of tree kernel module fails, as it can't find the include files.

To reproduce

sudo apt install raspberrypi-kernel-headers
git clone https://github.com/blokaslabs/pisound.git
cd pisound/pisound-module
make
...
  DTCO    /home/patch/work/pisound/pisound-module/pisound.dtbo
/home/patch/work/pisound/pisound-module/pisound-overlay.dts:23:10: fatal error: dt-bindings/gpio/gpio.h: No such file or directory
   23 | #include <dt-bindings/gpio/gpio.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:428: /home/patch/work/pisound/pisound-module/pisound.dtbo] Error 1
...

Expected behaviour
The .dtbo files should compile, here's a local workaround for dt-bindings:

sudo mkdir /usr/src/linux-headers-6.1.21-v7l+/scripts/dtc/include-prefixes
sudo ln -s ../../../include/dt-bindings /usr/src/linux-headers-6.1.21-v7l+/scripts/dtc/include-prefixes/dt-bindings
make

Then it builds just fine.

Getting the kernel source code through other methods (like the convenient but unfortunately deprecated rpi-source) didn't have such issue.

The raspberrypi-kernel-headers deb package should be fixed to not lose the essential include-prefixes directory, so out of tree kernel modules, containing device tree overlays, compile successfully without manual fixes to kernel sources.

We recognised that with the latest libraspberrypi0 package on Bullseye the library filenames have changed, with .0 appended, which broke several binaries from starting, even newly compiled ones, which are still looking for the shared objects without .0 endings.

I know there is no official RPi OS Bullseye release yet, so no problem with breaking changes, I just wanted to ask whether this has been done with purpose and whether these names are updated in other related packages. I'm not sure how those are pulled in by e.g. Kodi, MPD, MiniDLNA and some others. Even when recompiling against current libraspberrypi-dev, binaries are still looking for libmmal_core.so instead of libmmal_core.so.0, so somewhere this change is still missing.

Comparing jessie to stretch:

Only in sysroot-jessie/opt/vc/lib: libEGL.so
Only in sysroot-jessie/opt/vc/lib: libGLESv1_CM.so
Only in sysroot-jessie/opt/vc/lib: libGLESv2.so
Only in sysroot-jessie/opt/vc/lib: libOpenVG.so
Only in sysroot-jessie/opt/vc/lib: libWFC.so

This is version 1.20170703-2 which does not seem to be uploaded here yet.

We had a discussion on IRC today and it seems that under certain circumstances the bootloader/kernel postinst scripts can end up removing the only copy of the bootloader/kernel

The scenario we saw this in was a bootstrapping scenario and not on a Pi itself but I imagine this could also happen in other scenarios, for example if the postinst is interrupted partway through and later resumed.

So it seems like a good idea to make the code more defensive. In particular to make it check whether "/usr/share/rpikernelhack/<file>" actually exists before doing the remove and undivert dance on it.

The raspberrypi-kernel package sets INITRD=No before running postinst kernel hooks.
This means that update-initramfs never gets run even when an initrd is in use.

Is there a good reason for disabling that functionality?
Can you remove the INITRD=No setting from the kernel packaging?

Hi, I'm wondering if further firmware packages for stretch will be still released or these should be now considered deprecated?

In https://github.com/RPi-Distro/firmware/blob/debian/debian/changelog I noticed that the latest versions are being now labelled for buster with the latest version for stretch being 1.20190517-1.

Hopefully there are still plans to keep supporting Stretch, or at least you publish one more update to address the issue in raspberrypi#1144, which is affecting a significant number of users that for now will need to still use Stretch, i.e. RetroPie users.

Thanks in advance for the info!

Hello! I notice this error:

It seems to indicate that cross-compiling on say x86_64 host is not possible? Are these scripts being executed on Raspberry Pi itself? :)

I've seen the scripts in https://github.com/RPi-Distro/nightly, are there any more repositories of interest for building these packages? I'm interested in creating custom deb files for a custom kernel build.

Hi,

in debian/gen_bootloader_postinst_preinst.sh you have this lines:

cat <<EOF >> raspberrypi-kernel.postinst
if [ -f /etc/default/raspberrypi-kernel ]; then
  . /etc/default/raspberrypi-kernel
  INITRD=${INITRD:-"No"}
  export INITRD
  RPI_INITRD=${RPI_INITRD:-"No"}
  export RPI_INITRD

fi
...
EOF

so, you generate this snipped:

if [ -f /etc/default/raspberrypi-kernel ]; then
  . /etc/default/raspberrypi-kernel
  INITRD=No
  export INITRD
  RPI_INITRD=No
  export RPI_INITRD

fi

so, INITRD and RPI_INITRD is always "No". I think, it should be changeable via /etc/default/raspberrypi-kernel, or? I fixed it and added a patchfile to this issue: patch.txt

I did this some time:

-  INITRD=${INITRD:-"No"}
+  INITRD=\${INITRD:-"No"}
   export INITRD
-  RPI_INITRD=${RPI_INITRD:-"No"}
+  RPI_INITRD=\${RPI_INITRD:-"No"}

Regards