Spreadsheet comment 6 was intended to save my sanity when trying to keep an archive of multiple builds using multiple compilers (I have way too many cross compilers and several kernels for each compiler).
Assuming “/home/t32/” is synonymous with “”…
There is a script line wanting the uncompressed vmlinux kernel file, and names the “” directory as part of a full path (see: export KERNEL_ELF="/home/t32/vmlinux"). When actually running the Lauterbach software it apparently changes its working directory to “/bin/pc_linux64/”, the previous full path has the prefix thrown away, and so a second vmlinux file is needed in the new working directory. I created a symbolic link at “/bin/pc_linux64/vmlinux” which points at “/vmlinux”…that link, “/vmlinux” is itself a link to a directory containing multiple build configurations (those are the hard link real files). For me, this is at “/images//vmlinux-$(uname -r)”. All files of interest for preserving are placed there.
Example: Using Crosstool-ng-4.8.2, these real files exist:
<t32>/images/3.10.96-debug1_crosstool-ng-4.8.2/modules/...output of "make modules install.."
# make modules install has for example:
When I want to debug with that kernel those files are what I’ve actually booted to on the JTX1, and symbolic link “/vmlinux” points at:
Basically during kernel build module destination was “/images/3.10.96-debug1_crosstool-ng-4.8.2/modules/”. Changing just one vmlinux link keeps naming generic and my archive of various builds never needs to be touched or copied.
The overall work flow I use is build a new kernel, install with “uname -r” uniqueness, and basically copy the installed files to somewhere in “/images/”. Then I just change “/vmlinux” symbolic link to point at the correct “images” directory vmlinux (the same as the one booted on the JTX1).
<t32>/vmlinux # symbolic link.
<t32>/images/...somewhere.../vmlinux-uname-convention # what sym link above points to.
<t32>/bin/pc_linux64/vmlinux # symbolic link points at <t32>/vmlinux
All files distributed under the L4T documentation “baggage” for Lauterbach are unpacked in their respective L4T version directory, and a symbolic link added to all of them in “/bin/pc_linux64”. There isn’t much need to change those often, they should work for quite some time once edited. However, having them placed by symbolic link instead of hard file copy makes it obvious the files were not distributed with Lauterbach’s own install files (one can easily delete all of the sym links with “find -type l” and they won’t get mixed together).
If you get an error with that let me know, I’ll figure out what part of my environment let it work for me and add it to the spreadsheet. I always start in “/home/t32/”, so it is possible if you start the application from elsewhere finding vmlinux might break.