Linux: Upgrading the AM57x SDK

Nallapaneni,

We change the SDK frequently for several reasons:

1. The underlying open source software packages (U-Boot, Kernel, etc.) are constantly changing. We find it easier to keep up with these changes by constantly rebasing our changes against these and re-testing to quickly find problems.
2. These changes fix bugs and add features that we want to bring to SDK users, as you indicate your desire to move to systemd to have more control over boot process.
3. Customer feedback has told us that many users expect these frequent updates.

Our update schedule is basically 1/qtr. Approximately once a year we will move to the newest LTS kernel, appropriate U-Boot release, Linaro GCC toolchain, and Yocto branch. Our development is upstream for the most part even between these major releases so that our annual transition is manageable.

We understand that this may be more frequent than some users desire. However, the 3 benefits that I mention above, among others, pretty much make it necessary for us to update frequently. Given that, if you know that you will want to update in the future, I would recommend that you consider tracking our development as a part of your regular flow. You may choose to release on certain snapshots of this to your customer base and such support them. But, when you need a new feature, you will already be closer to the "head" where that new feature will probably be adopted. Most of this can be automated using standardized tools like git, jenkins, etc.

As for the specific task at hand, there is no "simple" path to porting from PLSDK 2.x to PLSDK 4.x. Major versions of the SDK indicate roughly annual releases. So, as you can see, this is a two year jump. 2 LTS kernels with a few intermediate kernels in between. 2 major versions of U-Boot. In the open source world, this represents many, many changes that hopefully represent fixed bugs (with relatively few new ones introduced) and new features. As I'm sure you can see, I list of files that have changes across this broad gap would be difficult to comprehend.

That being said, we do our development in the open and reveal all the changes that we can via our repos. The SDK contains git trees for the kernel and U-Boot that can be used to evaluate what changes might apply to your porting effort. They are also both architected in a way that tries to isolate board level changes to specific places. You can actually witness this in your kernel patch set as most of your changes relate to Device Tree files, which are intended for H/W abstraction. You can see a similar theme in your U-Boot patches. In any kernel or version of U-Boot, the changes that you need to make for your board or platform will likely be isolated to these files.

I will not pretend that it is easy work, but the most straightforward path is to use git as best you can, organize commits into clean patches, manage these in trees that can easily be rebased onto the trees that TI provides, and port each feature as necessary as changes happen. Some will go quite smoothly, others will require a bit of work to understand how the underlying code changed and do some re-architecting to account for it. Linux and U-Boot maintainers, as well as many open source developers around the world use these tools daily to move very large code bases forward each and every day.

I'm sorry I can't provide an easier path, but I hope my explanation provides some benefit to you.

Kind regards,

Ron