iurly
Posts: 19
Joined: Sun May 14, 2017 10:50 pm

Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 9:34 am

Hi,

I'm using a custom-built shield including a MAX3107 SPI-to-UART converter.
I had to enable and build the max310x.c module (since it's not enabled by default, not even as a module) and write a custom device tree overlay. For convenience, I did all this on the target itself, by downloading the kernel source (rpi-source) and building against it.

However, I wouldn't want to do this again and again:
a) on every system I am currently managing (many of them)
b) every time I update the kernel using rpi-update

What do you think would be a reasonable workflow for deploying this feature in a sustainable way?
Submit my changes to https://github.com/raspberrypi/linux and hope/wait for them to be merged and rebuilt?
Fork the https://github.com/raspberrypi/firmware and push my binaries there somewhere?
Try to package my binaries as a .deb somehow? Would there be a way to make the module kernel-independent?
Even if there's a way of doing this automatically, I wouldn't want to download the whole kernel source on every system and rebuild everything again and again.
Any other ideas?

Thanks!

feelslikeautumn
Posts: 297
Joined: Wed Aug 09, 2017 9:51 pm

Re: Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 10:56 am

Normally distributions (like Ubuntu etc) package the header files of the kernels. Then you can use dkms to automatically compile your module. This can be packaged up easily for other users to then use. It is how proprietary drivers work.

feelslikeautumn
Posts: 297
Joined: Wed Aug 09, 2017 9:51 pm

Re: Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 11:24 am

Submit my changes to https://github.com/raspberrypi/linux and hope/wait for them to be merged and rebuilt?
Probably this on raspbian.

iurly
Posts: 19
Joined: Sun May 14, 2017 10:50 pm

Re: Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 3:46 pm

feelslikeautumn wrote:
Wed Aug 30, 2017 10:56 am
Normally distributions (like Ubuntu etc) package the header files of the kernels. Then you can use dkms to automatically compile your module. This can be packaged up easily for other users to then use. It is how proprietary drivers work.
Yes, I also read about dkms (never used it though).
If I understand it correctly, I can install the source code on the target system and have dkms automatically recompile it and install it every time the kernel version changes (provided you also have the kernel headers).
Well, this would probably be overkill. I'd rather have some precompiled module which can be force-loaded and live with the fact that future kernel updates might actually break it.
Would that make any sense?

iurly
Posts: 19
Joined: Sun May 14, 2017 10:50 pm

Re: Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 3:48 pm

feelslikeautumn wrote:
Wed Aug 30, 2017 11:24 am
Submit my changes to https://github.com/raspberrypi/linux and hope/wait for them to be merged and rebuilt?
Probably this on raspbian.
Do you have any idea who I might ask and how?

feelslikeautumn
Posts: 297
Joined: Wed Aug 09, 2017 9:51 pm

Re: Packaging customized kernel modules and DT overlays

Wed Aug 30, 2017 4:14 pm

https://github.com/raspberrypi/linux/issues ?

I don't think force loading a compiled module is a good idea. The rpi kernels can take big jumps in version numbers and you don't know what has changed.

I don't know a lot about raspbian. Are there different kernels in raspbian that are more like the debian/ubuntu/etc ones? With proper header packages? If there are you could switch to them. I have some experience of dkms.


jdorel
Posts: 1
Joined: Wed Apr 17, 2019 1:39 pm

Re: Packaging customized kernel modules and DT overlays

Wed Apr 17, 2019 1:46 pm

Sorry for bumping a old thread, but did you eventually release your Device Tree Overlay anywhere ?

Thanks

iurly
Posts: 19
Joined: Sun May 14, 2017 10:50 pm

Re: Packaging customized kernel modules and DT overlays

Wed Apr 17, 2019 7:25 pm

Ehm, no, not officially at least.
If you're interested in the MAX3107, you can find the intermediate status at https://github.com/iurly/linux/commits/rpi-4.4-max3107

P.S. Just so you know, in the end that chip was abandoned on my part because of the fine print in the datasheet stating it might occasionally drop some bytes in the FIFO, and the fact that the HW design did not provide an external clock source. The internal oscillator --which I somehow managed to get to work by relying on deprecated documentation-- is not officially supported because of its intrinsic unreliability.

Return to “Raspbian”