11 Replies Latest reply on Nov 13, 2014 9:18 AM by mjstanis

    Custom kernel patch failing

    mjstanis

      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

        • 1. Re: Custom kernel patch failing
          mhahn

          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

          • 2. Re: Custom kernel patch failing
            Intel_Alvarado

            Hi mjstanis,

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

            Regards

            Sergio

            • 3. Re: Custom kernel patch failing
              MarcIII

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

              • 4. Re: Custom kernel patch failing
                mjstanis

                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

                • 5. Re: Custom kernel patch failing
                  MarcIII

                  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 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.

                  • 6. Re: Custom kernel patch failing
                    mjstanis

                    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

                    • 7. Re: Custom kernel patch failing
                      mhahn

                      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.

                      • 8. Re: Custom kernel patch failing
                        MarcIII
                        • 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.

                        • 9. Re: Custom kernel patch failing
                          mjstanis

                          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

                          • 10. Re: Custom kernel patch failing
                            Zigenz

                            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

                            • 11. Re: Custom kernel patch failing
                              mjstanis

                              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