Sorry, this is a lot longer than needed, but it is likely other people will also need to understand what is happening (which goes beyond a simple recipe for using Auvidea’s carrier)…
Changes to .c/.h files or .dts/.dtsi files demonstrate that the Intel features are added only through kernel source, and not device tree. Any device tree changes are apparently only for the Auvidea carrier board.
This shows that the Auvidea features are added only with the device tree, and do not change kernel source (kernel “source” is a subset of the kernel “package”…device tree is the complementary subset of the kernel “package”).
Both Intel and Auvidea changes are packaged within the kernel package, but are essentially autonomous from each other so far as build dependencies go. Neither build cares that the other exists or does not exist (but there will be a run time failure if they use incompatible configurations…configuration is what these share in common).
I can only speculate that the reason for Auvidea providing kernel Image and modules (even if only device tree changed) is due to a change in “uname -r”, which in turn would change where modules are searched for. Can you confirm what the “uname -r” is with the Auvidea changes in place?
You could boot an unmodified Jetson on a dev carrier, save a copy of “/proc/config.gz”, and then save the “/proc/config.gz” from booting an Auvidea kernel on the Auvidea carrer…then compare the two configs. It would be a really good idea for you to save a copy of both of those configs for later reference anyway…you may need to know at some later date when you build a kernel. While you are at it, save the extracted device tree while booted to each kernel. Example:
dtc -I fs -O dts -o extracted_`uname -r`.dts /proc/device-tree
(you will probably want a copy of these to examine in the future when you no longer have the original kernel and device tree…every developer should save a copy of this in a safe place from the original unmodified kernel and from any modification you are keeping)
As mentioned, the kernel source contains both the kernel itself and the device tree, but both being present is just for packaging convenience since drivers and device tree are related…but they are independent in actual build and often edited independently. If only device tree changed, then it is reasonable that Auvidea’s source is just device tree files. If you were to build your own kernel, e.g., “make Image” (zImage is the same thing, it is just compressed…not used with U-Boot on the 64-bit releases of Jetsons), then the device tree files could be completely missing and the build would never know (nor would the compiler care…it is only when the “dtc” script is used that device tree files matter). Conversely, if config is set up correctly and you are just building device tree files, then all of the kernel source files could be completely missing and dtc would not care.
To integrate all of the changes it seems that basically, if you take the existing TX1TX2 kernel source from source_sync.sh, apply Intel’s files and patches to the C portions, and then overlay Auvidea’s device tree files on top of that, then you would have everything integrated into a single package. Should this source tree be first correctly configured, then the build targets for Image, modules, and dtbs (“dtbs” is a build target, e.g., “make dtbs”; “Image” is a target, e.g., “make Image”; “modules” is a target, e.g., “make modules”), then your result would be everything in one package. Placing the new Image in the right place, and placing the new device tree files in the right place, followed by flashing, should result in everything going where it is needed (“flash.sh” copies the Image and device tree files based on arguments it is given…the rest comes from “rootfs/”).
There may be other adjustments to account for, e.g., if the new Image has a different “uname -r”, then the “rootfs/lib/modules/$(uname -r)/” would need modules copied there as well (“flash.sh” does not know the “uname -r” of a modified kernel, it only knows where the script originally says to place it…“rootfs/lib/modules/4.4.38-tegra/”). The caution to point out is that at the time of flash building the system.img that the actual “rootfs/boot/Image” and other boot related files are edited, so you can’t just put the Image there…it’ll be in one of the “Linux_for_Tegra/kernel/” subdirectories, and options to flash.sh will determine which device tree files and Image file are copied in to “rootfs/” (you edit what is in “Linux_for_Tegra/bootloader/”, “Linux_for_Tegra/bootloader/”, or other locations of “Linux_for_Tegra/” which are not “rootfs/” if you want to flash a modified boot configuration…all other changes go into “rootfs/”). I can’t tell you exactly what would change, I’ve never used Auvidea’s hardware.
For reference, if you are using L4T R28.2 (see “head -n 1 /etc/nv_tegra_release”), then the R28.2 source_sync.sh can obtain the full kernel package via:
./source_sync.sh -k tegra-l4t-r28.2
If you cd in to the “sources/kernel/kernel-4.4/”, you will see that this is from a git repository. “git status” can look at changes. Should you unpack the Intel patches and Auvidea device tree, then in theory it will point out exactly what has changed. Only the changes which the specific build configuration uses (which source_sync.sh won’t have…this is why you copy original “/proc/config.gz” and note “uname -r” for CONFIG_LOCALVERSION) will go into your TX2. If you log the flash of the TX2, then you will know which files were copied into the system.img.