This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] TDA4VM: Best practices for version tracking for TI’s SDK

Part Number: TDA4VM

This FAQ is intended to provide general guidelines of version tracking on TIs PDK to make it easier to track and share the code changes between customers and TI support.

  • Please note that this FAQ takes example of ti-processor-sdk-rtos-j721e-evm-08_02_00_05, but the guidelines remains similar for other Jacinto SDKs as well.

     

    Setting up Git

    There are several components in the PDK that are maintained as separate repos on TI side. This section provides details of setting up separate git repos for those components so the repos are similar on TI side and customer side making it easier to share patches.  

    Initialize a git repo at top level PDK folder.

    • Download and install the SDK from TI’s website. For j721e RTOS SDK use the link https://www.ti.com/tool/download/PROCESSOR-SDK-RTOS-J721E
    • Once the SDK is installed go to PDK top level directory and initialize a git repo.
      1. cd ti-processor-sdk-rtos-j721e-evm-08_02_00_05/pdk_jacinto_08_02_00_21/
      2. git init
    • Add a .gitignore file to avoid tracking the components that are maintained as separate repo. Please refer to the .gitignore file used for J721e 8.2 RTOS SDK. .gitignore
    • For each of the components included in gitignore like csl, cpsw, enet, etc, go to their respective folders and do a git init.

    Initial Commit

    Do initial commit for each of the repos before you make any changes. This will allow you to share your changes against the original version.

    • Run the following command after adding the .gitignore file and before making any changes
      1. git add --all
      2. git commit -s

    Creating Patches

    Now we can make the required changes. It’s always a good idea to make a separate branch before making any changes. This way you can always switch to the original version without much effort.

    • Make sure there are no untracked changes before you switch to a new branch
      1. git status
    • Switch to a new branch if the current working tree is clean
      1. git checkout -b example_branch
    • Make the required changes
    • There are many ways to create patch from here
      1. If you are sharing any patch for the first time with TI support, it is always good make sure you capture all the changes done against the original version
        1. If all the changes are in a single commit run the following command to create a patch

    git diff ID1..ID2 > example.patch

    Where ID1 is the commit ID of the very first initial commit

    Where ID2 is the commit ID of the commit for your changes

    1. If your changes pans across multiple commits, you can take diff against the master branch which is aligned original SDK

    git diff master example_branch > example.patch

     

    1. All the successive changes can be shared against previously shared changes.
      1. Make the required changes and create a patch for the current changes

    git diff > example.patch

    • If the changes pans across the different repos, create separate patches for each of them.

     

    Applying Patches

    • If you are receiving a patch from the TI Support for the first time, it will generally be against the original version. It is a good idea to move to a new branch before applying the patch
      1. git checkout master
      2. git checkout -b example_branch
      3. git apply example.patch
    • This will apply the patch. You can see the changes using git status and commit the changes if needed.

     

    • Any successive patch can be directly applied to the created branch