Kernel and driver support for new boards

Product support
1

Hi all,

Can you help me to understand how kernels and kernel drivers are supported and updated?

For example, I have a custom board based on an imx6qsabresd reference platform, so I believe the first job of work is to add support for this to resin-fsl-arm.

Next, there are various customisations needed to the kernel to support display, custom hardware on the board. Currently these are built into the kernel although it may be possible in future to move elements out into device tree and kernel modules.

So am I correct in thinking that the resin kernel is the running kernel and no other kernel (e.g. in a docker container) would have any relevance to the running system?

Given this I believe I would need to ensure that the resin kernel was built with all appropriate support for the board platform.

Lastly, if we require driver modifications then presumably it is possible to deploy modified kernel modules within a container image which could then be insmodded into the kernel?

The kernel is presumably configured by default to generate keyed kernel modules for that kernel.

Currently I’m looking at a adopting a process where I generate an OS image for a board which can then be deployed directly to that board without Resin.io. Then modifying that image for use within a Resin.io container for deployment within Docker. Can you advise if it will be enough to adopt the same kernel revision for my OS image as that used by Docker, which would then mean that any kernel module driver changes made will be deployed and be insmoddable into the Resin.io image kernel? Or are there other issues to be considered here?

Thanks,

Alex

2

Hi ajlennon,

For example, I have a custom board based on an imx6qsabresd reference platform, so I believe the first job of work is to add support for this to resin-fsl-arm.

Adding support for your board in reisn-fsl-arm is the first step, yeah. The way this works is by referencing the appropriate kernel sources for your board in a Yocto recipe. This means that if those sources contain custom drivers for display etc, the resulting image will get them too. As an example this recipe references sources from frescale’s git repos.

So am I correct in thinking that the resin kernel is the running kernel and no other kernel (e.g. in a docker container) would have any relevance to the running system?

Yes, there is only one kernel running at any time. We don’t have a resin kernel as such.

Given this I believe I would need to ensure that the resin kernel was built with all appropriate support for the board platform.

What we do in Yocto regarding the kernel is making sure some options are enabled that are required for running containers. See here and here. If you inherit the kernel-resin in your custom recipe you should get the proper kernel as a result.

Lastly, if we require driver modifications then presumably it is possible to deploy modified kernel modules within a container image which could then be insmodded into the kernel?

Yes, this is our current suggested workflow for updates in the kernel, however we consider this a hack and not a good solution overall since, as you said, the modules have to be compiled against the right kernel sources which makes the host and the container tightly coupled.

We are working on host OS updates currently which is the preferred way of shipping updates to anything having to do with the host OS, including the kernel and kernel modules.

Can you advise if it will be enough to adopt the same kernel revision for my OS image as that used by Docker, which would then mean that any kernel module driver changes made will be deployed and be insmoddable into the Resin.io image kernel? Or are there other issues to be considered here?

It should Just Work ™. I’m not aware of any obstacles. In fact, most of our boards use custom kernel sources from each particular vendor.

- petrosagg

1 Like
3

That’s really helpful. Thanks Petros.

4

Hi,

we have similar setup - we use custom board for Edison and so we need to compile and load drivers. Can that be sorted out in docker container?

For now building custom resinOS is not any option. We need to get hardware ready for deployment asap.

5

Hi @Przemek ,
it looks like you could do it like this: https://github.com/resin-io-playground/kernel-module-build
Can you give it a look and try it on your side please?

6

I did sth similar in a mean time, and it works. All because Docker container runs in the privilledged mode so there is access to kernel stuff.

Thanks for the help!

7

Glad it works.
Can you maybe details here what you did just so it remains here for other users in the future please?

Did it involve more than what our test example linked above does? If not, then there’s nothing else to describe I guess

8

So I compiled drivers on Intel Edison. Then I use insmod to install it. And that is in the start.sh script which is executed as last docker container command.

Your example is a complete solution I think.

9

Okay, glad things are working for you now.