New version for L4T 28.2.1 with new features

[Shreeyak]

Hey! This is just an FYI - I wanted to let you know that I'm working on adding changes for this repo to work with the new L4T 28.2.1 for the TX2.

I'm also working on some new features and would love to get your inputs on them:

• Download kernel sources from Nvidia's git repo directly. Eg: http://nv-tegra.nvidia.com/gitweb/?p=linux-nvmap.git;a=commit;h=fc9b7fa02156503ada6fff3d71d388ca521d1130
• Detect version of L4T on the TX2 and download the corresponding version of the kernel sources automatically. No need for different releases for each kernel version.
• Some improvements to the detection of L4T version on TX2. Note: the current code clips the version to 2 decimals (eg - 28.2) and that would not work with kernels with 3 decimals like (27.2.1, 28.2.1).

[Shreeyak]

After this, I'll also be making the changes to the buildRealsense2 repo, which uses this repo internally.

[jetsonhacks]

Hi Shreeyak, First, thank you for this. I have been thinking about going this route for awhile. This is where I eventually winded up in my thinking.

If this is being done professionally (as opposed to the intentions of a maker/hobbyist version such as JetsonHacks), the correct way would be to use (or create) scripts based on the NVIDIA source_sync.sh script. These scripts would download the Git archive and ultimately give much finer grain control than the 'snapshot' approach presented here. This also implies that there is a person (or peoples) which would maintain the script and that approach. There is overhead in maintaining the scripts. Also, it has been my experience that the kernels usually need patches to be able to run them on the device, so would need to be added to the local Git archive of the kernel source. Ultimately it is much more robust for a larger organization (or someone who has a larger stake on this particular process).

In the approach presented in this repository, it basically copies a tarball of the source, applies patches if need be, and uses Github for the revision control. It's not "nice" or particularly user friendly, but it reads simply and doesn't require much maintenance per release other than figuring out the URL of the compressed kernel source. I convinced myself that this is probably simpler for people who do not have much experience with building kernels or reading scripts; I always think of this as shell script 101 rather than writing 'real' scripts like your submission.

Of course as time has gone on and cruft has built up, this assumption may not be as true. However, with Xavier release coming up, I'm not sure how much work will need to be done to get the kernel to compile onboard.

Anyway, that's my thinking on this, I just change the URL and do some clean up now and then and let the users struggle a bit if need be to figure out which version they need.

[Shreeyak]

Thank you for laying out your thoughts, Jim. And a big thank you for the public mention!

I actually went down this route because I couldn't figure out the URL for the whole source's tarball, haha. Upon reviewing my submission, I see that your method is indeed much simpler to read and understand. Thanks for taking the time to simplify things - it helped me a lot in understanding the process.

I will consider making a more "proper" approach to building kernels, perhaps even the method of flashing from the host PC. Looks like there isn't any nice guide/tutorial on the subject out there.

[Shreeyak]

Notice: This pull-req is still a work in progress!! It is not ready to be used as is.