I’m doing some work putting together an environmental system for Bees. As a part of this I discovered Pimoroni’s Enviro+ which is a neat little integrated sensing board. As we’re leveraging what we are doing with Balena’s platform I thought I’d have a go at supporting Enviro+ with Balena
I had more trouble with this than I expected and I said to @bucknalla I’d put some notes down.
There’s no criticism here. I knew what I was getting into would be fiddly just because of the nature of Docker, modules and Linux kernels. That said, while I remember, some of this might be useful feedback for the team from a customer who has been through it.
Annoyingly Pimoroni have a nice install script but it expects Raspbian and does various things with raspi-config and config.txt so I had to do my own thing. C’est la vie.
So the bulk of the Enviro+ Docker template was quite easy, just tracking down dependencies. I have my container running in privileged mode which although non-ideal from a security perspective is good enough for me (PRs always gratefully accepted of course!)
I ran into trouble with the MEMS microphone on the Enviro+ as it wasn’t being detected as a card. I ended up going all over the place trying to work out exactly what this was, and how to support it.
Long story short I had to add a driver which isn’t present in BalenaOS. This means I then had to build that driver for the kernel running on my BalenaOS device, in this case balenaOS 2.54.2+rev1
Now my first port of call via Google was this set of instructions from the Resin.io days
I like this as I understand it and it’s pretty straightforward but for whatever reason I couldn’t get it working. The files for my BalenaOS couldn’t be found for some reason. I assume that things have changed since this was written and if so it would be worth putting a note in deprecating it? Or maybe I just didn’t understand what I was doing wrong!
So then I moved onto the more recent example here
So this is a great effort to help - thanks for that!
I found it really hard to work out what was going on, partly as I was using this within a DockerFile and going around and around the houses trying to figure out what was going wrong.
A couple of things that would help
this is for out of tree modules only. I suspect a lot of people just want an in-tree module added so it would really help to have a simple parameterised script that builds an existing in-tree module
the searching for the kernel tarball and the kernel modules tarball is quite obscure. It would be really helpful to have a blog description of how this is working to find the right files
we have to set the BalenaOS version (and potentially the Linux kernel version). it would help if this was an ENV variable we could just use against a specific device (not sure how doable this is if Apps can have Devices with different BalenaOS versions though?)
the way the get_and_build() function works by going through twice in sequence is clever but really obscure. It would make the process a lot clearer to break out the pulling of module tarball, the pulling of kernel tarball and the building of the in tree or out of tree module
it also takes quite a while when you are testing so if these processes could be seperated it allows the search + pull to be cached to make it easier to test the building
when I finally did get to look at the kernel source file I assumed it would be a full buildable kernel (i.e. including .c files) but it seems only to have includes and such which meant I couldn’t build the in-tree module I wanted. I might have gotten this wrong as it seem a bit odd.
The ability to add in custom in and out of tree modules feels relevant as I am sure some users need this like me and I really don’t want to have to go to the trouble of setting up a full Yocto+Balena environment to build my own custom host OS image.
So those are my thoughts. Offered in the spirit of support and feedback! If I think of anything else I’ll add it in
Hi Alex, thanks for the notes and summary above, it is very helpful. We have given the use case of both in-tree and out-of-tree kernel modules built a lot of thought lately and you will be glad to know that we are working towards a solution that should make this much easier in future.
Some remarks on your notes above. What is referred to as “kernel source” is actually just kernel headers that are used to build external modules. BalenaOS is not currently releasing the kernel source as a built artifact but it is something that we are also working towards.