Yocto / Torizon + Custom Kernel + Kernel Module + Network Mgmt + Apps [Architecture Help Neded]

Hello.
Torizon + Torizon OTA is AWESOME!
I’ve been using Buildroot to create all the code that runs on my device. I’m seriously considering the move to Torizon. I need a few things:

  1. I need to patch the kernel.
  2. I need to include a kernel module.
  3. I need a UI to control device settings, including network and another app.
  4. I need to control the network from the UI.
  5. I need to run an app with an editable config.

I was able to build a default Torizon OS in Yocto, and now I’m ready to move forward.

My issue is this:

If I build a .NET Core app and run it in a container to manage the device, how can I “reach back” to the main OS to make calls to nmcli? Should I just run this control app in the main OS?

Greetings @kdubious,

Glad to hear you’re having a good experience with Torizon.

As for your issue, it is possible to run Network Manager inside a container. See the on this post here: Change the apalis imx6 static IP address from inside a container

Give this a try and let me know how it works out. As for the other things on your list let us know if you have any questions or issues with those as well when you get to them.

Best Regards,
Jeremias

Thanks for that link, Jeremias.

I think I understand the overall strategy now.

  1. Patch the kernel with Yocto.
  2. Add my kernel module with Yocto.
  3. Build my management tools with NetworkManager included in that container.
  4. Allow my management container to write config files for my app container. (where is best? These need to survive an OTA update)
  5. Create my app container with Yocto.
  6. Have my app container read the files. (where is best? These need to survive an OTA update)
  7. Sleep
  8. Coffee
  9. Launch

Where best to put the shared config files, then? A volume on the main OS? How do I deal with keeping that file (with its user customizations) during Torizon OTA updates?

Patch the kernel with Yocto.

Correct

Add my kernel module with Yocto.

If it’s an out of tree kernel module you can add it using torizoncore-builder as well. See here: Building External Kernel Modules With Torizon | Toradex Developer Center

Build my management tools with NetworkManager included in that container.

Correct

where is best? These need to survive an OTA update

For OTA updates we use OSTree. Some directories in OSTree are handled differently during an update. Specifically /etc and /var, see this section here for more info on how these are handled: OSTree | Toradex Developer Center

Create my app container with Yocto.

Oh you’re constructing your containers using Yocto? This can work, but out of curiosity any reason you’re deciding to construct your containers this way?

For the most part though it sounds like you got the right plan forwards.

Best Regards,
Jeremias

So once I have my custom kernel / device tree from Yocto, can I do everything else with torizoncore-builder? (It is an out of tree kernel module)

@jeremias.tx I’m struggling to work out the right way to “edit” the kernel source code. Can I fork the Toradex source, edit it, and include in Yocto my repo instead of the one from Toradex? Do I need to make a new Yocto layer that applies patches to the kernel source?

I’ve seen docs on DTS, I think I can follow that. I’m also good on options for including kernel modules. But I need to make some code changes to the kernel source itself.

So once I have my custom kernel / device tree from Yocto, can I do everything else with torizoncore-builder? (It is an out of tree kernel module)

You should be able to. Simpler changes and configurations to the image can be done with torizoncore-builder rather than Yocto. But check our developer page to make sure the tool supports what you’re trying to do.

Can I fork the Toradex source, edit it, and include in Yocto my repo instead of the one from Toradex? Do I need to make a new Yocto layer that applies patches to the kernel source?

You can do either, a fork works as well or just applying patches on top at build-time. Depends on your needs and use-case whichever makes most sense. We have an article about doing some Yocto customizations: Custom meta layers, recipes and images in Yocto Project (hello-world examples) | Toradex Developer Center

For kernel customizations we show a method for patching on top of our default kernel.

Best Regards,
Jeremias

Hello @jeremias.tx

I’m able to build with bitbake torizon-core-docker. Is that the right thing to do after I added my Custom Layer?

How do I best include additional packages?

Also, I have torizon/kiosk-mode-browser:2 and torizon/weston:2 on the machine. I don’t need the kiosk.

I’m able to build with bitbake torizon-core-docker. Is that the right thing to do after I added my Custom Layer?

Should be, assuming you’ve done your changes such that they affect the torizon-core-docker recipe.

How do I best include additional packages?

First of all, is there a reason you need to include these packages at the Yocto level? Or could these be added in a container?

Also, I have torizon/kiosk-mode-browser:2 and torizon/weston:2 on the machine. I don’t need the kiosk.

Then just simply remove the kiosk container. Those containers are just for evaluation purposes and initial experience. They are by no means permanent fixtures in the OS.

Have you gone through our quick start and documentation on the container workflow that we promote with TorizonCore? You sound a bit new to the topic still and I wouldn’t want you to go through unnecessary complications trying to do things in other ways.

Best Regards,
Jeremias

I’m really struggling with the custom-meta-layers-recipes-images-in-yocto-project article. I wonder if things have changed since the article?

My current error is:

make[2]: *** No rule to make target ‘arch/arm/boot/dts/my-custom.dtb’. Stop.

ERROR: Execution of ‘/home/kdubious/torizon/build-torizon-upstream/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/linux-toradex-mainline/5.4.161+gitAUTOINC+9af15300c7_ed9c66090d-r0/temp/run.do_compile.22087’ failed with exit code 1

Wait if you’re just trying to add your custom device tree you can also just use torizoncore-builder for that. See here: Device Tree Overlays on Torizon | Toradex Developer Center

There’s no need to go through yocto for device tree. The only one of your requirements that requires yocto is the kernel patch you mentioned. Everything else should be doable with either torizoncore-builder or done inside a container.

Best Regards,
Jeremias

Feels like a silly question, but here goes:

The docs lead me to believe that I need to create my own image recipe, however I don’t think I need to, do I? I’m planning to build the torizon-core-docker, but with my kernel patches, DTS and kernel module.

But these images are considered reference images and should not be used in products directly, instead one should derive a custom image from them.

If I’m to build my own image recipe, can I include the appropriate “.inc” files that the reference image includes?

When I don’t create my own recipe, and I run bitbake torizon-core-docker, It doesn’t seem to do anything with my DTS. When I rename recipes-kernel/linux/linux-toradex_%.bbappend to recipes-kernel/linux/linux-toradex%.bbappend, things happen. But, I’m still getting the wrong content in my DTB, becuase I disable the default sound card in my DTS, and it appears in my running device.

Any thoughts on this? I think the docs are not a perfect match for my scenario (imx7).

Thanks.

The docs lead me to believe that I need to create my own image recipe, however I don’t think I need to, do I? I’m planning to build the torizon-core-docker, but with my kernel patches, DTS and kernel module.

What “docs” are you referring to?

Also if you are using our TorizonCore distribution then there are very few cases where you actually need to create your own image using Yocto. With TorizonCore most changes can either be done in a container or with TorizonCore Builder. However if you are patching the kernel source as you claim then this is one of the cases you need to use Yocto. To be clear I assume you’re patching the kernel source, if this is a device tree patch that can be done with TorizonCore Builder

If you are using our Yocto reference distribution then you need to use Yocto for any kind of customization.

If I’m to build my own image recipe, can I include the appropriate “.inc” files that the reference image includes?

You can or you can not. It ultimately depends on what you are trying to do with your image build.

When I don’t create my own recipe, and I run bitbake torizon-core-docker , It doesn’t seem to do anything with my DTS. When I rename recipes-kernel/linux/linux-toradex_%.bbappend to recipes-kernel/linux/linux-toradex%.bbappend , things happen. But, I’m still getting the wrong content in my DTB, becuase I disable the default sound card in my DTS, and it appears in my running device.

We would need to comprehensively go over what your changes are in Yocto to even understand what is going on in your build. Though again if you are using TorizonCore you can do device tree changes much easier with TorizonCore Builder. Otherwise we’d have to walk through Yocto.

The thread here is becoming quite hard to follow. I suggest just focus on one thing, do that one thing, then move on to the next thing. You are trying to do device tree changes right now. As I said I suggest using TorizonCore Builder for this task, because you are using TorizonCore therefore it will be simpler.

Best Regards,
Jeremias

Hello Jeremias,

I’m following this article:
Custom Yocto

I do need to patch the kernel.

The article above shows how to use my custom DTS during the Yocto build, but those instructions do not seem to work for me.

The article above shows how to use my custom DTS during the Yocto build, but those instructions do not seem to work for me.

Did you try to debug this?

Is your device tree being built? Is it being included in the final image? Is it being selected as the default device tree on boot?

We need to narrow down something more specific than “do not seem to work”.

Also I still don’t see why you need to do the device tree customization in Yocto when you can use TorizonCore Builder as I’ve been suggesting. The only thing that needs to be done in Yocto is your kernel patch.

Best Regards,
Jeremias

Did you try to debug this?

As best as I could, yes.

I’m pretty sure that the DTB is getting built. I’m also pretty sure that uBoot is not instructing the device to use my DTB. Can you tell me the file I should look for to see if this is having the right effect:

** recipes-bsp/u-boot/u-boot-toradex_%.bbappend

do_configure_append() {
	sed -i 's/#define FDT_FILE.*/#define FDT_FILE "my-custom-devicetree-file.dtb"/' ${S}/include/configs/colibri_imx6.h
}

I’d prefer to do “all” my kernel work in Yocto. There are a lot of pieces that come together, and this workflow makes the most sense for my scenario.

Wait that snippet of recipes-bsp/u-boot/u-boot-toradex_%.bbappend that you just shared. Is this how it appears in your Yocto build?

According to how you tagged your question you’re using the Colibri i.MX7 is that correct?

If both of the above questions are true, then what you have in your bbappend is incorrect. Notice how the bbappend is modifying a file colibri_imx6.h. If you are using the Colibri i.MX7 you’d need to modify the appropriate file for that module.

In your built image you should be able to check if it’s taking effect or not. In the U-Boot console just check the value of the environment variable fdt_file. See if the value matches what you’re setting in your bbappend here. Also check the filesystem of your built image to see if your my-custom-devicetree-file.dtb is actually being built and deployed to the final OS image.

Best Regards,
Jeremias

Hi Jeremias,

Yes, iMX7 (and 2020 uboot). I did change ${S}/include/configs/colibri_imx6.h to ${S}/include/configs/colibri_imx7.h, and forgot to mention that.

iMX7 2020 UBoot Header File

BUT, I see that these 2 files (imx6 and imx7) do not share the same line related to setting the FDT_FILE. And so now I’m stuck as far as how to tweak the value being used by uboot.

BUT, I see that these 2 files (imx6 and imx7) do not share the same line related to setting the FDT_FILE . And so now I’m stuck as far as how to tweak the value being used by uboot.

The difference is because the imx7 header file is used by both the raw NAND and the eMMC versions of the Colibri i.MX7. So we can’t just statically define a single device tree since both variants require different device trees.

Now looking in the imx7 header file you reference you can see the line:

setenv fdtfile ${soc}-colibri-emmc-${fdt_board}.dtb && run distro_bootcmd;

You probably just need to simply edit the line so that fdtfile gets set to whatever your device tree is.

Best Regards,
Jeremias

You’d

I don’t see that line.