Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
2,130 Views

Custom kernel patch failing

Hi all,

I'm trying to apply two custom kernel patches to fix Precision Time Protocol (PTP) support. I have placed the patches into the meta-clanton_v1.0.1/meta-clanton-bsp/recipes-kernel/linux/files/ directory and added the files to the meta-clanton_v1.0.1/meta-clanton-bsp/recipes-kernel/linux/linux-yocto-clanton_3.8.bb as done with other patches in the patches.txt from the latest BSP instructions.

I then ran bitbake linux-yocto-clanton -c menuconfig to set my options, but I received the following error:

DEBUG: Executing shell function do_patch

WARNING: no meta data branch found ...

Checking out files: 31% (11026/34971)

...

Checking out files: 100% (34971/34971), done.

Switched to branch 'linux-3.8.y'

[INFO] validating against known patches (clanton-standard-meta)

[ ] (|)(0 %)

...

[# ] (\)(100 %)

error: stmmac_main.c: does not exist in index

To force apply this patch, use 'guilt push -f'

[ERROR] unable to complete push

pending patches are:

links/files/stmmac_main.patch

links/files/stmmac_ptp.patch

ERROR. could not update git tree

ERROR. Could not apply patches for clanton.

Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto-clanton)

ERROR: Function failed: do_patch (see /home/matt/meta-clanton_v1.0.1_sdk/yocto_build/tmp/work/clanton-poky-linux/linux-yocto-clanton/3.8-r0/temp/log.do_patch.9995 for further information)

Looking at the patches with the latest BSP instructions, they have a diff --git command and an index line like the following:

diff --git a/drivers/tty/serial/intel_quark_uart.c b/drivers/tty/serial/intel_quark_uart.c

index 5bb6a00..2297691 100755

--- a/drivers/tty/serial/intel_quark_uart.c

+++ b/drivers/tty/serial/intel_quark_uart.c

...

My patches have neither:

--- stmmac_main.c~ 2014-09-11 15:43:14.615441622 -0700 +++ stmmac_main.c 2014-09-11 18:43:30.100824044 -0700

...

It looks like I need to get the index hash from the Kernel.org Git repo, but I'm not sure how to best go about finding the right index.

How do you find the proper index to put in the patch file?

Thanks!

Matt

11 Replies
Highlighted
15 Views

that shouldn't matter. However, what I am unsure about is the use of different file names (*.c vs *.c~)

Typically you do have your folder a with the original code and folder b with the modified code but all filenames within identical (or within git an original branch vs a modified branch).

I guess your patch can't work that way.

My 2 cents

Highlighted
Employee
15 Views

Hi mjstanis,

Do you still have questions with this post? Let us know if you still need assistance.

Regards

Sergio

0 Kudos
Highlighted
Employee
15 Views

Since you don't seem to be using git (why not?), change directory to the top-level kernel directory before running your diff command.

Highlighted
15 Views

Hi Sergio and Marclll,

Yea, I could still use help on this.

I'd be glad to use Git, I'm just unfamiliar with how to find the right hash to diff the file I want. I would like to follow the same procedure that the rest of the patches use to access Git and patch the correct version of the file, so if you have tips on finding the right hash for the files I need to patch, I'm all ears :-)

Thanks!

Matt

Highlighted
Employee
15 Views

You don't need any hash value, text before the triple --- is ignored.

There are a number of ways/diff commands to create a patch and they can all work. Which one are you using?

The problem you seem to be having is just a path problem. The "patch" command has a fairly elaborate algorithm to find the file to patch (see http://linux.die.net/man/1/patch patch(1): apply diff file to original - Linux man page) but in practice the problem is usually just an incorrect number of subdirectories. Change directory before running your diff command until the number of directories at the start of your output follows the example of working patches. Also have a look the error in the file pointed by the error message you quoted.

0 Kudos
Highlighted
15 Views

Hey MarcIII, thanks for the tip. Yea, I thought it must be a path problem as well. However, the patch still does not seem to be taking, despite being able to now run the bitbake all the way through.

Currently, here's what I'm doing:

  • Place the patch files into meta-clanton_v1.0.1/meta-clanton-bsp/recipes-kernel/linux/files (see attached)
  • Add the names of the two patch files into linux-yocto-clanton_3.8.bb (see attached)
  • Run bitbake linux-yocto-clanton -c menuconfig, configure any options I want
  • Run bitbake image-sdk-galileo
  • Try out my image

So far, the patches don't seem to be sticking (I look at the kernel source on the booted Galileo image and don't see my changes in stmmac_ptp.c and stmmac_main.c). I also tried manually adding some printk statements to the stmmac_ptp.c source in the tmp/work dir of my bsp build directory, but re-running bitbake and trying that image had no results either (no printk statements).

I also no longer receive the error I used to get in my first post above (error: stmmac_main.c: does not exist in index...), but I'm guessing it's because I ran through bitbake once without my patch files. Now, when I re-run bitbake commands in the same directory with the patch files added, they're not getting added in incrementally, so I no longer see the errors. Perhaps that's my problem; I'm going to rerun bitbake after clearing out my tmp directory with the current patch files attached (which have their paths fixed I believe) and see how it goes.

I thought my issues was because I'm not using the git command to pull in the right file to diff during the bitbake, but you mention that other diff/patch methods work as well. Can you look at the above process and patch files and let me know if there's something I'm missing?

Thanks!

Matt

0 Kudos
Highlighted
15 Views

I just recently patched the kernel for stmmac which worked fine.

I'd recommend looking into your build/tmp/work/.../stmmac/ folder and check what's happening there. Also check the log outputs and maybe try patching manually in order to better understand possible issues.

0 Kudos
Highlighted
Employee
15 Views

  • Now, when I re-run bitbake commands in the same directory with the patch files added, they're not getting added in incrementally, so I no longer see the errors. Perhaps that's my problem; I'm going to rerun bitbake after clearing out my tmp directory with the current patch files attached (which have their paths fixed I believe) and see how it goes.

There is one easy way to see if your new patches get applied or not because of some build cache issue: forcibly break them again somehow and run "bitbake" again: bitbake must then complain. If it does not then you have a build problem. Forcibly breaking something is always a very simple and effective way to make sure a change is actually taken into account.

I thought my issues was because I'm not using the git command to pull in the right file to diff during the bitbake, but you mention that other diff/patch methods work as well. Can you look at the above process and patch files and let me know if there's something I'm missing?

Patches have existed long before git was born; git is certainly not the only way to generate a patch. A plain "diff" command is the simplest. The patches you attached look correct.

0 Kudos
Highlighted
15 Views

Yea, it turns out that I wasn't clearing my cache for my image build properly, so the patch files weren't getting applied. I now have my patch files working and I've fixed a few bugs with them that were causing kernel panics.

I want to thank mhahn for helping me out via email, as we've been able to make quite a bit of progress in getting the IEEE 1588 (PTP) timestamping to work on the Ethernet port of the Galileo. However, I've run into a bit of a snag when running gptp to test timestamping. Whenever I run gptp on a PTP-enabled Galileo connected to a PTP-compatible switch or between two PTP-enabled Galileos, I receive the following repeating errors:

Invalid TX

ERROR at 677 in ../../common/ieee1588port.cpp: Error (TX) timestamping PDelay request, error=-72

ERROR at 1071 in ../../common/ptp_message.cpp: Error (TX) timestamping PDelay Response (Retrying-0), error=-72

ERROR at 1083 in ../../common/ptp_message.cpp: Error (TX) timestamping PDelay Response, error=-72

After speaking with a few people, it sounds like there's still an issue with the stmmac kernel driver and how the timestamps are being handled. Digging into the gptp code itself doesn't offer too much insight into what an error -72 really means. If anyone has more insight into the STMicro drivers (stmmac and stmmac_ptp), I'd be very thankful.

Once I get hardware timestamping up and running, I'll be glad to report back the steps to get up and running :-)

Thanks!

Matt

0 Kudos
Highlighted
New Contributor I
15 Views

Hi Matt - any progress on this front?

Short of actually digging into the driver code, you could try running a different PTP suite (e.g. linuxptp or ptpd) on two Galileos and see if threw a more meaningful error message.

Cheers,

Z

0 Kudos
Highlighted
15 Views

Hey Z,

My team member who knows the driver code much better just returned this week, so I've written up my initial HOWTO instructions on enabling PTP (even though it is broken) so that he can get started playing with a Galileo and see what he finds in the kernel driver. All queries I made to the Quark and AVB folks point at the driver as the most likely issue.

I did give ptp4l a shot, which does run, but only for software timestampping, not hardware. With software timestamps, we were seeing synchronization down to the order of us, not ns.

Will keep you posted and will post my HOWTO with the patches once we get everything working.

Thanks!

Matt

0 Kudos