Creating local oe-core patches

Hi,

I’ve read through all the Toradex articles, watched the various Toradex (and Yocto) videos, and read as many relevant community questions as I could find, and feel that I’m starting to understand how to put together a custom layer with custom image and patched kernel and u-boot. One area I wasn’t able to find a clear answer, is in the use of the following commands from here:

git commit -m "patch name"
git format-patch --signoff HEAD~1

Having created patches previously using diff file1 file2 > patchname.patch directly previously, I understand the intent of these commands, but wanted to make sure they pertain solely to local/private files. I.e. do either of the git commands upload any of the patch content, git user/email, etc. to the public git repository, or is the ‘commit’ only made on the local clone of the git repository?

I’ve tried using devtool to source and maintain a local source workspace for both the linux-toradex and u-boot-toradex directories, but as a beginner it’s very hard to apply the Toradex articles and community posts to this method as they all use the git-based approach instead.

Any clarification in this space would be greatly appreciated!

Hi

The use of git is one way to get to the patches.
When using git you have the advantage of not having to keep the original file(s) around and you can add a sensible commit message explaining what your patch changes.

There is no behind the scenes changes/uploads done and if you prefer you can keep using your diff workflow.

I personally do not use devtool for any such work, so I cannot comment.

Max

Thanks @max.tx

I won’t persist with the devtool workflow for now; I’m happy to use the diff approach provided I understand how to build from local source. It might make it a little more clear if I outline exactly what it is I’m trying to achieve below.

In my ~/toradex folder I have an oe-core directory, a kernel directory and a u-boot directory.

The oe-core directory is setup using repo init -u http://git.toradex.com/toradex-bsp-platform.git -b LinuxImage3.0 -m default.xml and then repo sync. The kernel directory contains the relevant source for linux-toradex, with a matched revision/hash for the current LinuxImage3.0 source. Similarly, the u-boot directory contains the relevant source for u-boot-toradex, with a matched revision/hash for the current LinuxImage3.0 source.

What I’d like to do is be able to create a custom meta layer within oe-core (I’ve already done this), using the local kernel and u-boot source (in the ~/toradex directory) to build the image, with patches created using diff file1 file2 > patchName.patch using the various local files (e.g. imx6q-apalis-eval.dts for patching the carrier board device tree).

Where do I need to make changes so that bitbake will build from these local sources rather than from git? From the reading I’ve done, it seems that this is possible (e.g. from this Yocto document), but I’m unsure how to make the required download mirror changes to the stock oe-core repo folder to point to both the local kernel folder and local u-boot folder.

It looks like I’ve put together a suitable workflow; I’m now able to use a local kernel source to generate the required patches, and then use the standard git repository for the actual build which appears to be working nicely.

One outstanding issue I have is regarding the use of the the image_type_tezi.bbclass. I normally use the TEZI output folder and modify the uEnv.txt and image.json accordingly before flashing the device via USB. In my meta-customlayer/conf/machine/mymachine.conf file I’ve added IMAGE_CLASSES_append = " image_type_tezi" which adds the toradexlinux.png, prepare.sh, wrapup.sh and marketing.tar files/folders to the /deploy/images/customimage directory, but it doesn’t generate the image.json file? The meta-toradex-bsp-common/recipes-bsp/tezi-metadata/tezi-metadata_0.3.bb file doesn’t include image.json, so from where is it generated when building a standard Toradex recipe?

Never mind, it seems I was a little hasty in posting the above comment :smiley: I had missed a couple of key properties in my machine.conf file pertaining to the TEZI process as shown here. I added the various properties through trial and error and now a fully prepared TEZI folder is generated in the build/deploy/images/customimage/ directory as expected. Hopefully someone in the future having this same issue is able to make use of the above ramblings :slight_smile:

@jars121: Can you explain in more detail, how you modify the uEnv.txt and image.json files? Do you do this by hand/script after the bitbake process or is it integrated your image recipe?