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

Technical Support
, , ,
22

Here’s the solution (for an iMX7 emmc based board, at least)
meta-customer/recipes-bsp/u-boot/u-boot-distro-boot.bbappend

do_install_prepend () {
    sed -e '/^otaroot=.*/a fdtfile=my-custom-devicetree-file.dtb' -i ${WORKDIR}/uEnv.txt.in
}
23

Here’s the solution (for an iMX7 emmc based board, at least)
meta-customer/recipes-bsp/u-boot/u-boot-distro-boot.bbappend

Oh I suppose that works as well. Just keep in mind you’re changing the uEnv.txt file rather than U-Boot. So if this file you’re modifying ever changes or we stop using it this solution will no longer work.

In general all you need to do is set the U-Boot environment variable fdtfile to whatever your device tree is.

The method I was showing you before changes the default value of this method in U-Boot.

I don’t see that line.

Also apologies I was looking at the file locally and I didn’t have an updated file from the repo. In the latest U-Boot code the default value of fdtfile is set here in the defconfig instead of the header file: colibri_imx7_emmc_defconfig « configs - u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

One issue I can see with the approach you’ve taken is that since you’re setting the value of fdtfile in uEnv.txt. This overrides anything you set in the U-Boot environment for this variable. Meaning you can’t just trivially change it anymore, which is fine for production but in development can be a bit annoying if you just want to quickly switch between 2 device trees. But I suppose this is up to you.

Best Regards,
Jeremias

24

OK, I’ll look at your method and get back to you.

25

I am about to pick things back up, starting with Torizon 7.

I have the same set of concerns as before.

The docs now suggest this:
“We recommend changing the kernel outside of Yocto to reduce the integration and test cycle time. Please follow the instructions in this article: Build U-Boot and Linux Kernel from Source Code.”

Is this accurate? Does it imply that I don’t need to build anything with Yocto now?

Or is the Yocto approach the right one?

26

The docs now suggest this:
“We recommend changing the kernel outside of Yocto to reduce the integration and test cycle time. Please follow the instructions in this article: Build U-Boot and Linux Kernel from Source Code.”

I believe the docs have always had this statement no? At least I can see the same statement back in the 6.X.Y and 5.X.Y version of this document.

Is this accurate? Does it imply that I don’t need to build anything with Yocto now?
Or is the Yocto approach the right one?

You never technically had to use Yocto. To customize these things. Though personally I still would recommend Yocto. If you do it the other way you’d be building a standalone U-Boot and/or Kernel binary from source directly. Then you’d have to shove these binaries into an existing image. This process can be very error prone. Then you’d have to somehow production program your devices with this hacked together image. It’s also not a good way to have a reproducible image build, compared to Yocto which is meant to be a reproducible build environment.

Compared to Yocto where it will produce an image with all your customization and you wouldn’t need to figure out how to hack binaries into it. As well as produce a production image that can be distributed across your devices.

Again though as I said 3 years ago I would really make sure whether what you need to do actually requires Yocto, or whether it can be done with TorizonCore Builder.

Best Regards,
Jeremias

27

Hi Jeremias,

I have historically had to edit / patch the kernel source to accommodate a higher frame rate for PCM audio than the kernel had by default.

The current fsl_sai.c file now has those changes in it already. However, the 2 other files I needed to change in the past do not have the higher rates. I suppose I can try to use the kernel with no edits and see if my kernel module works.

I suppose my other steps, as you’ve pointed out in the past, can all be accomplished with TCB.

28

It wouldn’t hurt to check on Torizon 7.X, given the newer kernel version. The behavior of these things could have changed since you last you tried in the older version.

Best Regards,
Jeremias

29

I’m working my way through moving things to 7 and using only TCB.

Currently, I’m having issues with my Device Tree file. It’s not a layer, it’s an actual .dts file that includes 2 Toradex files.

// SPDX-License-Identifier: GPL-2.0 OR MIT
/*
 * Copyright 2017-2021 Toradex
 */

/dts-v1/;
#include "imx7d-colibri-emmc.dtsi"
#include "imx7-colibri-eval-v3.dtsi"

In my tcbuild.yaml, I had:

  device-tree:
    # >> Directories where to look for include files.
    include-dirs:
      - linux/include
    # >> Custom device tree source:
    custom: mp-a-cappella-iii.dts

but the compiler complained about not being able to find the 2 included files. Moving my DTS file to the linux/arch/arm/boot/dts/nxp/imx/ path seems to have worked. Should do something else, though?

30

but the compiler complained about not being able to find the 2 included files. Moving my DTS file to the linux/arch/arm/boot/dts/nxp/imx/ path seems to have worked. Should do something else, though?

I mean that is expected no? Look at where the device tree files are now located in the version of the Linux kernel used in Torizon 7.X. As I have been saying the version of the Linux kernel used in Torizon 7.X, is much newer than what you were using before. Such version changes can introduce many changes. When migrating to a new version it’s imperative to expect changes and plan ample time to the adapt your process.

For reference this change did not come from Toradex, it came from the Linux community as a whole: https://github.com/torvalds/linux/commit/724ba6751532055db75992fc6ae21c3e322e94a7

Best Regards,
Jeremias

31

I’m sorry, I wasn’t clear. I assumed (but I see that I’m wrong) that this example from the docs:

  device-tree:
    # >> Directories where to look for include files.
    include-dirs:
      - linux/include

was somehow going to wire up this line at the top of my .dts file:

#include "imx7d-colibri-emmc.dtsi"

I see now, after some more trial and error, that all I needed to do is add the right include directory:

  device-tree:
    # >> Directories where to look for include files.
    include-dirs:
      - linux/include
      - linux/arch/arm/boot/dts/nxp/imx/
32

I’m still a bit confused on what point you’re trying to make.

You’re saying you had to list the include directory linux/arch/arm/boot/dts/nxp/imx/ in order to use the include statement #include "imx7d-colibri-emmc.dtsi". But, this should all be expected. I mean the file imx7d-colibri-emmc.dtsi is in this directory in the Linux kernel source as seen here: linux/arch/arm/boot/dts/nxp/imx/imx7d-colibri-emmc.dtsi at v6.6 · torvalds/linux · GitHub

The linux/include directory is more for things like *.h header files, not for *.dtsi files.

Best Regards,
Jeremias

33

I was trying to use my own device tree in TCB.

I mistakenly translated:

customization:
  device-tree:
    include-dirs:
      - linux/include
    custom: linux/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
    overlays:
      add:
        - device-trees/overlays/colibri-imx6_hdmi_overlay.dts

into this:

customization:
  device-tree:
    include-dirs:
      - linux/include
    custom: device-trees/my-custom.dts
34

So there’s no issue then and everything is good on this topic?

Best Regards,
Jeremias

35

Yes, I’m good, and the code is good. Might be nice to update the docs with an example of using your own device tree (not an overlay).

Thanks for your patience, and help.