You can build without it being on an external drive. However, if you have more than one Jetson, or you want to share between two computers which are not connected by network and/or do not have Internet access, or if there is not enough disk space on the particular device, then you can use an external medium which you can connect or disconnect as needed. It is a convenience when working on any of those cases. Everything works perfectly well without that though, so it is just choice.
The file itself will not help. This is just the core of a kernel module, and you need the surrounding content to turn it into a module. Modules load into the kernel, and thus it isn’t that different to a lock and key…if the module is not compiled to fit the ABI (Application Binary Interface), then it will not load. If the module is not compiled to fit against your kernel Image, or if the Image has changed and the modules have not, then you have a problem. If you’ve set up your kernel environment correctly, and then change only modules, the ABI will work as expected. You need the full kernel source, not just a file, and that kernel source needs to be configured to match the running kernel.
In your case when not using removable media you can just ignore the parts designed for moving it around between computers. Everything will just be in one place, but the procedures for kernel configuration still apply. Do you have the full kernel source code here:
/home/robo/R36.3.0/Linux_for_Tegra/source/kernel/kernel-jammy-src/
?
If so, then you can:
cd /home/robo/R36.3.0/Linux_for_Tegra/source/kernel/kernel-jammy-src/
export SRC=`pwd`
echo $SRC
Based on your other directories, you can set up like this (not all of these are strictly required, but it helps with clarity; the echo statements are just to verify; see notes just below this):
cd /home/robo/R36.3.0/
export BASE=`pwd`
echo $BASE
cd /home/robo/R36.3.0/build_pl2303
export TEGRA_KERNEL_OUT=`pwd`
echo $TEGRA_KERNEL_OUT
cd /home/robo/R36.3.0/modules_pl2303
export TEGRA_MODULES_OUT=`pwd`
echo $TEGRA_MODULES_OUT
cd /home/robo/R36.3.0/other_pl2303
export CONFIGS=`pwd`
echo $CONFIGS
cd /home/robo/R36.3.0/image
export ARCHIVE=`pwd`
echo $ARCHIVE
Notes:
SRC is often called TOP instead. This is just where the software looks for build content.TEGRA_KERNEL_OUT is the workhorse. This is where all of the build content and temp content goes and is why you can leave the original source untouched. The original source is best keep readable by all but writable only by root; actual build should not be performed by root.TEGRA_MODULES_OUT is a location where one can output all of the module information once they are built. Not strictly needed, but the work to separate out what this does in a second is far too much. This will create a directory tree in TEGRA_MODULES_OUT which is shaped just like the destination computer’s directory structure, and will contain files to be copied in. As an example, after you’ve built modules and then modules_install with INSTALL_MOD_PATH=$TEGRA_MODULES_OUT you will see an entire “lib/...lots of stuff.../”, and that “stuff” will contain all of the modules in a mirror of the directory tree where they eventually get copied. You don’t need all of those if you only want the PL2303 and did not alter the integrated features. It is easier to find the PL2303 content in $TEGRA_MODULES_OUT than it is $SRC (a.k.a., , $TOP).- I would have created a
configs_pl2303/ directory, and I am assuming this is what you named other_pl2303. This is where you keep configurations for various purposes. It is a reference library. The intent is that you name configs there with some name that has meaning, and then when you need it, copy it to the empty “$TEGRA_KERNEL_OUT” as file name “.config”.
- I am assuming that your kernel
Image (and perhaps other files) are being saved in $ARCHIVE, but I could be wrong about your intent of what you want there. Whatever purpose you have in mind just use it consistently like that and name an environment variable after it for convenience.
There is in fact your next step: Set up the environment variables. You could add those in an alias in your ~/.bash_aliases, source the file, and run the alias; this would set up the environment variables for that session on that terminal. Assuming those are set up, do this once:
cd $SRC
sudo make mrproper
Since you said you are on your host PC, this means you are cross-compiling. Previous steps were accurate, but not including cross-compile details. This means the instructions will differ some. To start with, where are your cross-compile tools? Perhaps they are at one of these locations:
/usr/aarch64-linux-gnu/bin//usr/bin/~/usr/aarch64-linux-gnu/bin/
The point of the above is that you will need a cross-compiler when building on the host PC and not building on the Jetson, and that the location can vary. You will need another environment variable for whatever that cross-compiler is (you don’t need this on a native build; in fact, someone using some of the cross-compile environment for a native build will end up failing). I’m going to pick “/usr/bin/” as the location. If that is the correct location, then you will find a series of files there, and all will have this prefix to their name:
aarch64-linux-gnu-
When you build natively, you use gcc; when you cross build, you use aarch64-linux-gnu-gcc.
When you build natively, you use ld; when you cross build, you use aarch64-linux-gnu-ld.
When you build natively, you use as; when you cross build, you use aarch64-linux-gnu-as.
So on, so forth, etc. The kernel build, when told to cross compile, understands to use a special environment variable to substitute for the correct cross compiler. On 64-bit ARM that environment variable is CROSS_COMPILE. All of the previous environment variables were for the developer and could be named many things and still work. This particular environment variable is specifically understood by the kernel build system itself, and so this should not be changed, and if you are not cross-compiling, it should not be set.
For my example, I will set it like this since you are on the host PC (in which case you must cross-compile and cannot natively compile):
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
Do change that if your cross tools are in another location. Note that this is the full path up to and including that special “aarch64-linux-gnu-” prefix. When kernel build wants gcc, it will prepend the $CROSS_COMPILE; if this is empty, then it just looks for gcc. If that CROSS_COMPILE is /usr/bin/aarch64-linux-gnu-, then it will instead find “aarch64-linux-gnu-gcc”, which is still gcc, but it is the cross compiler version for 64-bit ARM.
In addition to setting CROSS_COMPILE to the correct prefix you must also tell the compiler what the architecture is, arm64. This too is an environment variable which must be set for cross compile, but cannot be set for native compile (it would appear to build, but the result would be wrong):
export ARCH=arm64
In summary, cross-compile is going to add these:
export CROSS_COMPILE=/some/where/aarch64-linux-gnu-export ARCH=arm64
If you are not cross compiling, then you must unset those two if they were previously set. In some cases a variable can be used both on command line or as an environment variable, so you might see some redundant statements.
An example of building the default configuration setup, but adding PL2303 follows. Your SRC/TOP content should be pristine and untouched. The temp output location for $TEGRA_KERNEL_OUT and $TEGRA_MODULES_OUT should be empty. A regular user should do this, not root.
cd $SRC
# This is default configuration.
make O=$TEGRA_KERNEL_OUT ARCH=arm64 defconfig
# Enter the context-sensitive editor.
make O=$TEGRA_KERNEL_OUT ARCH=arm64 nconfig
# Use the symbol search function and find the location of the PL2303 feature.
# Use the "m" key to set it as a module.
# Save and exit.
# Verify this exists:
ls $TEGRA_KERNEL_OUT/.config
# When done you could save that:
cp $TEGRA_KERNEL_OUT/.config $ARCHIVE/config-tegra-pl2303module
# If you ever wanted to use that again, and TEGRA_KERNEL_OUT is empty:
cp $ARCHIVE/config-tegra-pl2303module $TEGRA_KERNEL_OUT/.config
That is now configured to the default configuration, but adds a module. You don’t need the Image, but it is a really good idea to build it once as an acid test. This also means you don’t need to build “modules_prepare”; if you skipped Image, then you would need “modules_prepare” instead. Here is building the main Image:
cd $SRC
make -j 8 O=$TEGRA_KERNEL_OUT ARCH=arm64 Image
Note that in the last command I added “-j 8”. This is the job server, and it uses up to 8 CPU cores. Does your host PC where you are compiling have fewer or more CPU cores? You can adjust this to match for best speed. If you lack RAM and run out of RAM, then you would use fewer cores.
Now, if Image built, or if you instead built modules_prepare, you can build modules:
cd $SRC
make -j 8 O=$TEGRA_KERNEL_OUT ARCH=arm64 modules
# If they built, copy them into the temp holding location:
make O=$TEGRA_KERNEL_OUT ARCH=arm64 modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
You should now see an entire tree of files in $TEGRA_MODULES_OUT. Modules themselves are normally located at “/lib/modules/$(uname -r)/kernel/”, and so you will now find these at:
$TEGRA_MODULES_OUT/lib/modules/...the "uname -r" of the new kernel.../kernel/
You might find this useful:
find $TEGRA_MODULES_OUT/lib/modules/ -iname '*pl2303*'
You could also find the Image file from here and copy that to $ARCHIVE:
find $SRC -type f -name 'Image'
Have you modified the original kernel though? If not, then just the PL2303 .ko file needs copy to the right location (also an “sudo depmod -a”, perhaps a reboot). If you changed the Image, then you need the new Image and you also need 100% of all of the files. There might be another complication if out of tree modules are needed; in that case you’ll end up with something more extensive to get that out-of-tree content.