How Toradex starts and maintains the Linux git repo (for Freescale/NXP based SoMs in particular)

Hello,

I got a question to understand about the process which Toradex follows to maintain (and evolve) it’s Linux kernel Git repo. I’m in particular interested in the Freescale/NXP SoC based products.

I’ve mostly worked against the Freescale/NXP released BSP, and the tags or branches of the linux-imx repo matching the releases they make. Thus for example, for the iMX’s last release was/is imx_4.9.11_1.0.0_ga, which was last year September sometime or so. As I’ve asked on NXP forum, it seems, between the releases, they do not make public any updates or development that goes on, and thus there is no branch updates or fixes or changes that the general public can access (at least no one answered differently on their forum).

What does Toradex do? From what I see by examining the Git log, it seems Toradex starts with NXP’s sources release / tag , in this example rel_imx_4.9.x_1.0.0_ga. (As here rel_imx_4.9.x_1.0.0_ga , but there is a little mismatch to NXP’s rel_imx_4.9.x_1.0.0_ga tag, seems they’ve re-tagged it latest 2017-11-20, while Toradex’s tag is from 2017-09-07, so a bit of mismatch). And then there are many updates on Toradex’s repo going on top of this almost every month till now.

Who does these updates, is this all from Toradex internal developers? Do you also follow some other linux-imx repos, and sync with other projects using linux-imx, and other manufacturers using the SoC?
Do you may be have access to NXP’s internal linux-imx updates /changes which they do not mirror in their public repo, so you always in sync with them? And if not, what do you do when they release their updated BSP, how do you incorporate this, do you pick the changes you want (cherry picking…?) or, do you start again from the new BSP branch / tag, and try to rebase (if that is right term) all your changes based on previous BSP from them… ?

Would be great if you could help out to understand this flow. May be it’s ‘standard’, but I’m not very experienced in working with and especially following Linux kernel/u-boot sources from different places, and from different SoM/CoM manufacturers, and what is a normal practice here. How do different companies sync on latest source changes (and may be don’t fix same bugs ) ? I thought there might be a common linux-imx project on kernel patch-work , but, I do not see any ( or didn’t find it…).

So hope you won’t mind clarifying this.

And lastly, if I wanted to submit some patches, relating to the iMX sources specifically, where is right place to email to suggest them? (May be Stefan Agner can review and might accept them ???)

Thank you in advance

You may find a general explanation about our support strategy here. In the NXP case, as you may have found out from our roadmap, we usually sync with the community fslc stuff plus of course the regular Yocto Project meta-freescale stuff. On top of that, we, of course, also keep working with our hardware and fix bugs or integrate enhancement along the way.

In parallel, we do upstream aka mainline support for all our hardware. And more and more we try to follow the upstream first principle (e.g. make sure any issues we discover are first fixed upstream before being packported to downstream). However, as you may know, upstreaming/mainlining is a somewhat delicate process outside of our direct control. Basically, nobody, not even my top contributor @stefan.tx can do miracles when it comes to upstreaming/mainlining. It is a process that takes time and resources, many a clever developer giving feedback along the way.

Anyway, if you have fixes/suggestions you may send them to resp. upstream mailing list as noted in resp. readmes. Alternatively, you may send them to our support address in order for us to have a look at.

Hey Marcel, thanks for replying.

Thank you for the provided link on roadmap, to be honest I cannot see anything on that roadmap page referring to NXP or the linux-fslc community project.
Does ‘upstream’ mean the main Linux kernel sources? (i’m sorry if this is obvious…)

But from what you wrote, Toradex kernel sources are from / syncs with :

  1. NXP official Linux BSP (Yocto’s meta-freescale refers to it);
  2. Github’s community project freescale/linux-fslc;
  3. Toradex’s own work
  4. Upstream (main) Linux kernel

Thank you for referring to support, that’s definitely was my first consideration, as I have been in contact with Stefan previously.

Hey Marcel, thanks for replying.

You are very welcome.

Thank you for the provided link on roadmap, to be honest I cannot see anything on that roadmap page referring to NXP or the linux-fslc community project.

What I wanted to refer to was e.g. the following resp. the later.

Does ‘upstream’ mean the main Linux kernel sources? (i’m sorry if this is obvious…)

Yes, mainline (rather than main) and upstream may be used interchangeably.

But from what you wrote, Toradex kernel sources are from / syncs with :

First. NXP official Linux BSP (Yocto’s meta-freescale refers to it);

Second. Github’s community project freescale/linux-fslc;

As a matter of fact, from a Linux kernel source perspective, the NXP official BSP (e.g. what you refer to by 1.) already get’s integrated here.

Third. Toradex’s own work

Yes, our hardware specific changes plus further enhancements.

Fourth. Upstream (main) Linux kernel

If parts from upstream/mainline are used in our downstream kernel sources, this is usually called back-porting.

Thank you for referring to support, that’s definitely was my first consideration, as I have been in contact with Stefan previously.