[Software version control] How to version control nvidia and custom code?

Hi NVIDIA Team,

When we using Linux_for_Tegra, it is inevitable that we will add some of our own customized code. However, NVIDIA software version itself is also accelerating its iteration. This brings a lot of problems to the code repository updates and iterations.

In this scenario, how does NVIDIA recommend managing the above-mentioned code repositories so that the customer’s own code is easy to update while also not affecting the synchronization update of NVIDIA’s code?

This is just my opinion, but I think if there are issues, then you have to learn .deb packaging, especially naming dependencies. If some content from NVIDIA has a package, and if this has some interference, then you might make your software depend on that package. I don’t think anyone can give a reasonable answer if they don’t know details on what your software touches, e.g., if it is used in boot, if it is a kernel feature, if it depends on a kernel feature, if it is a driver of some sort, if it involves firmware (the device tree), if it is all user space, etc…

Hi @linuxdev ,

Thanks for your kindly reply, The above reply may not answer my real concern. My core question is: how to Iterate customer code and NVIDIA official code simultaneously.

For example, directory jetson_35.5.0/Linux_for_Tegra/sources/kernel/nvidia/drivers/media/ Nvidia While updating the bugfix, we also need to add some customized code here.

When jetson linux is updated to r36.2.0 or higher, how can the previously added customized code be synchronized to the latest r36.2.0?

Is there any way to prevent these changes from interfering with each other?

THANKS!

Hello,

I always create a copy of my current branch, then rebase it on the new tag provided by nvidia, using

git rebase --onto=NEWTAG OLDTAG mybranch

That’s not perfect and requires often manual edition, but that’s the best I have found.

2 Likes

As long as you are not touching the boot chain, including initrd and device tree and kernel, everything else should just be a package. However, you should have to stick to the NVIDIA kernel in R35.x. I like what @phdm is suggesting as it will detect changes. So far as changing from one major release (L4T R35.x) to another major release (such as R36.x) there is no simple update mechanism, you have to completely install the entire boot chain, device tree, kernel, so on. You can use tools like git to go from one R36.x release to another R36.x. Don’t even try with transition of R35.x to R36.x.

1 Like

Hi,
Please refer to the patch list:
Bring Your Own Kernel — NVIDIA Jetson Linux Developer Guide 1 documentation
Bring Your Own Kernel — NVIDIA Jetson Linux Developer Guide 1 documentation

You may upload your patches to upstream kernel, or maintain your own git based on upstream kernel. For example, if your kernel is based on v6.7, you would need the two patches:

92a511a568e4 fbdev/simplefb: Add support for generic power-domains
8ddfc01ace51 fbdev/simplefb: Support memory-region property

are the vi/csi drivers (e.g. vi4_fops) already pushed to upstream kernel ?

Hi,
Our driver code is in kernel_oot_modules_src.tbz2. If your patch is in the driver code, you may share to us and we will review to include it into future release.

I do not speak for the OP, but that’s what I do, and I am still waiting for feedback. See

and

Hi,
We have checked the patches with our teams. And since we don’t have the camera source generating frame data in the format, so we are not able to do validation and include the patches. Please maintain the offline patches for your use-cases.

Should I understand that nvidia never tests the v4l2 way to capture frames ?

The sensors I work with have no special feature. They are Sony monochrome sensors, but the same tests could be conducted treating Bayer sensors as monochrome ones, especially when using the test pattern generator provided by the Sony sensors themselves.

Hi,
We have YUV camera sensors in YUV422 such as YUYV, UYVY. We don’t have the camera generating Y12_1X12, so are not able to do validation.

If you still have an imx185, you could replace in the (v1) driver

#define IMX185_DEFAULT_DATAFMT  MEDIA_BUS_FMT_SRGGB12_1X12

by

#define IMX185_DEFAULT_DATAFMT  MEDIA_BUS_FMT_Y12_1X12

I do not have the imx185 docs though, so I don’t know how to setup the pattern generator.