devtool modify linux-toradex applies patches from custom layer onto branch other than devtool

Technical Support
1

Hello,

I’m looking to get clarification on the proper way to make patches for linux-toradex.

As I understand it, devtool modify <recipename> should result in a repository with branch[es] like devtool[-override-*], and any custom patches for that recipe applied on devtool such that HEAD is at the most recent patch, and then you can continue working from there.

However, when I run devtool modify linux-toradex, devtool[-override-*] branches do not have my patches (from SRC_URI += " 0001-desc.patch 0002-desc.patch..." in my customlayer/recipes-kernel/linux/linux-toradex_%.bbappend file). But, the branch toradex_6.6-2.2.x-imx does have those patches.

My workflow/workaround has been to git checkout toradex_6.6-2.2.x-imx then make my commits and devtool finish linux-toradex /path/to/custom/layer. [1]

Unfortunately, that devtool finish results in all previous patch files being generated, then deleted from my custom layer, except for the ones created by commits I made during that devtool session.

If I merge toradex_6.6-2.2.x-imx into devtool (and correspondingly merge or rebase devtool-override-* branches as needed), this does not happen and the custom layer receives the patch files and updated .bbappend file. [1]

My coworker who is much more experienced with Yocto advised me that I should not be switching branches, that if devtool doesn’t have patches or incorrectly generates output patches, something is wrong in my configuration.

I got curious and asked ChatGPT about how to make these patches but I’m suspicious of its response: which was to switch branches to toradex_6.6-2.2.x, make the commit in devtool, manually generate the patch (git format-patch) and then manually copy the patch file into my custom layer and edit the .bbappend to include the new patch file in SRC_URI (thus and avoid using devtool <finish/update-recipe>).

What is the proper way to use devtool to modify linux-toradex?

Thank you much.

Footnotes:

[1] I notice that devtool finish linux-toradex /path/to/custom/layer results in my linux-toradex_%.bbappend file being updated. But if I do devtool update-recipe linux-toradex -a /path/to/custom/layer, a separate file linux-toradex_6.6-2.2.x.bbappend is created. This observation is only tangentially-related to my question but I thought it was interesting.

[2]: I did check the “related topics” that popped up while I was creating this topic, but none of them seemed relevant, topics 1 2 3 – I also searched the community and saw this topic but it didn’t quite seem to be what I was looking for either.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Proper Workflow for Modifying linux-toradex with devtool

Your observation about devtool modify behavior with linux-toradex is valid, and your coworker’s advice is correct—you shouldn’t need to manually switch branches when using devtool properly.

Recommended Approach

Based on Toradex documentation, the standard workflow for kernel modifications involves creating a .bbappend file in your custom meta-layer rather than relying solely on devtool for patch management(1).

Standard Kernel Customization Workflow

  1. Create the proper directory structure in your custom layer:
$ cd ../layers/meta-customer
$ mkdir -p recipes-kernel/linux/linux-toradex
$ touch recipes-kernel/linux/linux-toradex_%.bbappend

(1)

  1. Set up the .bbappend file to reference your patches:
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI += " \
    file://0001-your-patch.patch \
    file://0002-another-patch.patch \
"

(1)

  1. Place your patch files in the ../layers/meta-customer/recipes-kernel/linux/linux-toradex directory(1).

Why devtool Behaves This Way

The devtool branch behavior you’re seeing occurs because:

  • devtool modify creates its own workspace branches (devtool and devtool-override-*)
  • Patches from your .bbappend are applied to the base branch (toradex_6.6-2.2.x-imx) during the build process, not necessarily to the devtool workspace branches
  • This is expected behavior—devtool is designed for interactive development, while .bbappend patches are build-time modifications

Alternative: Manual Patch Generation

For kernel development, Toradex documentation suggests a more direct approach(2):

  1. Clone the kernel repository directly
  2. Make your changes and commit them
  3. Generate patches using git format-patch
  4. Place patches in your custom layer’s recipes-kernel/linux/linux-toradex/ directory
  5. Reference them in your .bbappend file

This avoids the complexity of devtool branch management for kernel work.

About the .bbappend Filename Difference

The difference between linux-toradex_%.bbappend and linux-toradex_6.6-2.2.x.bbappend you observed:

  • % is a wildcard that matches any version(1)
  • Specific version numbers target only that kernel version(1)
  • devtool update-recipe may generate version-specific files, while devtool finish respects your existing wildcard naming

Conclusion

Your workaround of switching to toradex_6.6-2.2.x-imx isn’t wrong per se, but it’s fighting against devtool’s design. For kernel modifications on Toradex modules, the cleaner approach is:

  1. Use the manual patch workflow described in the kernel build documentation(2)
  2. Manage patches directly in your custom layer’s .bbappend(1)
  3. Reserve devtool for application recipes where its workspace model fits better

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @hn7097,

This is a known issue of upstream Yocto when dealing with kernel recipes.
There have been many fixes to adjacent problems, but the issue you see is still present on Scarthgap.

Generally playing with branches manually when using devtool is not recommended.
However, if the result in your layers is correct and you clear the workspace after devtool finish, there should be no persistent issue, as the relevant metadata should be correct.

What I usually do is to just track my custom layer on a git repository.
When devtool removes/edits something that it should not, I can revert only the incorrect changes.
This is a bit of a manual approach, but should be fine for most cases.

Generally when you are working with the kernel and need many iterations, building the kernel directly is way more practical.
When the work is done, you can consolidate your patches and bring them to your layer.

Best Regards,
Bruno

4

I see, I guess ChatGPT was correct when it said this was a quirk specific to working with the kernel in Yocto.

It sounds like I have a couple options then:

  1. Build the kernel directly. For iterating, I can pull the existing patches from my layer into the kernel repo and build on top of them, and then like you said consolidate the work and generate updated patches into my layer.
  2. Continue with the git workflow. I usually git add -i to add the hunk/line that devtool puts into the bbappend, and then git restore to keep all the lines that devtool deleted. Or I can merge the base branch into devtool branch each time I start a new devtool session. Either way there’s some manual work, as you mentioned.

I can do either of these so I’ll get with my team and work however we decide on.

Thanks much @bruno.tx

5

I don’t know if it’s useful for you but in my case I found that the --disable-overrides argument to modify stopped devtool spawning a bunch of unrelated branches. Though in my case this was necessary because it kept trying to apply patches that would fail (on override branches) for completely different products and leave me unable to actually check out the source to begin with.

6

Thanks, that is actually very useful for me. I expect that with --disable-overrides, I won’t have to rebase devtool-override-* branches onto devtool or merge the latter into the former.

I previously had to do that because devtool finish would process devtool branch, then the override branches would process and if they didn’t also have the commits, the patch files would get deleted.