cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mcarosino
Visitor
Visitor
687 Views
Registered: ‎12-07-2018

Quickest way to re-build kernel with petalinux

Jump to solution

Hi all,

I'm trying to work out some nasty issues with a device driver that's requiring a lot of editing of the kernel and device-tree. The way i'm currently doing this in petalinux is by editing a kernel patch and then basically running "petalinux-build -c kernel -x cleanall && petalinux-build -c kernel". It's very time consuming (re-fetch kernel source, patch, compile, re-package fit image, etc).

 

I've found I can use rm_work_exclude on 'linux-xlnx' to avoid the scratch source from being deleted, and I can go edit that manually. But how can I tell petalinux to recompile this and then package it into the fitimage image.ub?

 

Or is there another way to speed up this process and make debugging a little easier?

0 Kudos
1 Solution

Accepted Solutions
patocarr
Teacher
Teacher
651 Views
Registered: ‎01-28-2008

@mcarosino 

  Making a kernel patch every time sounds like extra work. The way I'd do it, is to work on the actual kernel tree, without getting a patch until the fix is done. The patch then would be used to reproduce the build, for example on a new host.

  So, first we get the tool set to devtool, instead of bitbake, with petalinux-config-> Yocto settings-> Build tool.

  Then we get devtool to make the kernel source accessible for modification.

$ petalinux-build -c kernel -x modify

  Then, the source will be available under components/yocto/workspace/sources/linux-xlnx/, where you can edit at will and as long as you don't clear the tree (i.e. mrproper or cleanall), it will stay put. The build will use this kernel source including your edits.

  The source is source controlled by a Git instance, set on a 'devtool' branch. You can add commits as usual, and they will turn into a series of patches. At this point, there's two alternatives I know of.

a) Use devtool to move the patches between your commits and the base branch, back to your meta-user/recipes-kernel/linux/files/ and should update the bbappend recipe. You have to be careful here because there's a known issue that overwrites your current patches there, so make a backup of this directory. To actually copying the patches you'd issue:

$ petalinux-build -c kernel -x finish

b) In general this is what I use because of that known bug that overwrites the current patches in meta-user. The idea is to generate the patches by hand, copy them and update the recipe.

$ cd components/yocto/workspace/source/linux-xlnx
$ git format-patch HEAD~
$ cp 0001-my-patch-commit-log.patch <proj>/project-spec/meta-user/recipes-kernel/linux/linux-xlnx/

  The recipe would be updated in recipes-kernel/linux/linux-xlnx_%.bbappend to include the patch:

SRC_URI += "file://0001-my-patch-commit-log.patch"

  Once the patch is copied and the recipe is updated to read it, you can get rid of the kernel tree and your edits:

$ petalinux-build -c kernel -x reset

 

I hope that's clear enough.

Thanks,

-Pat

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

View solution in original post

4 Replies
patocarr
Teacher
Teacher
665 Views
Registered: ‎01-28-2008

Hi @mcarosino 

  I believe there's no need to erase the whole kernel build after every driver and/or device tree edit. Sometimes, something is not updated properly and requires a full rebuild, but I would try avoiding the erase and see how that plays out. You could include a variable under sysfs that gets bumped on each build to make sure the driver is at its latest version.

Thanks,

-Pat

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos
mcarosino
Visitor
Visitor
662 Views
Registered: ‎12-07-2018
Hi - as it currently stands, if I edit the kernel patch file directly, petalinux doesn't pick up that it got changed and won't re-apply it, hence the cleanall command. I wonder if it's because I'm hand editing the patch file. Perhaps if I actually create a new patch (e.g. have some kernel source set a side that I use to edit and generate patches from) and insert that into the project - then maybe petalinux will always pick it up..
0 Kudos
patocarr
Teacher
Teacher
652 Views
Registered: ‎01-28-2008

@mcarosino 

  Making a kernel patch every time sounds like extra work. The way I'd do it, is to work on the actual kernel tree, without getting a patch until the fix is done. The patch then would be used to reproduce the build, for example on a new host.

  So, first we get the tool set to devtool, instead of bitbake, with petalinux-config-> Yocto settings-> Build tool.

  Then we get devtool to make the kernel source accessible for modification.

$ petalinux-build -c kernel -x modify

  Then, the source will be available under components/yocto/workspace/sources/linux-xlnx/, where you can edit at will and as long as you don't clear the tree (i.e. mrproper or cleanall), it will stay put. The build will use this kernel source including your edits.

  The source is source controlled by a Git instance, set on a 'devtool' branch. You can add commits as usual, and they will turn into a series of patches. At this point, there's two alternatives I know of.

a) Use devtool to move the patches between your commits and the base branch, back to your meta-user/recipes-kernel/linux/files/ and should update the bbappend recipe. You have to be careful here because there's a known issue that overwrites your current patches there, so make a backup of this directory. To actually copying the patches you'd issue:

$ petalinux-build -c kernel -x finish

b) In general this is what I use because of that known bug that overwrites the current patches in meta-user. The idea is to generate the patches by hand, copy them and update the recipe.

$ cd components/yocto/workspace/source/linux-xlnx
$ git format-patch HEAD~
$ cp 0001-my-patch-commit-log.patch <proj>/project-spec/meta-user/recipes-kernel/linux/linux-xlnx/

  The recipe would be updated in recipes-kernel/linux/linux-xlnx_%.bbappend to include the patch:

SRC_URI += "file://0001-my-patch-commit-log.patch"

  Once the patch is copied and the recipe is updated to read it, you can get rid of the kernel tree and your edits:

$ petalinux-build -c kernel -x reset

 

I hope that's clear enough.

Thanks,

-Pat

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

View solution in original post

mcarosino
Visitor
Visitor
643 Views
Registered: ‎12-07-2018
Exactly what I was looking for, thanks so much Pat!
0 Kudos