# No acknowledge from i2c address **URL:** \ **Category:** Jetson Xavier NX\ **Tags:** i2c, board-design\ **Created:** [July 13, 2021, 8:23am UTC](https://forums.developer.nvidia.com/t/no-acknowledge-from-i2c-address/183489 "2021-07-13T08:23:18Z")\ **Posts on this page:** 1\ **Showing post:** 21
**Author:** ![linuxdev](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/linuxdev/32/10243_2.png) [@linuxdev](https://forums.developer.nvidia.com/u/linuxdev)\ **Post date:** [July 16, 2021, 6:07pm UTC](https://forums.developer.nvidia.com/t/no-acknowledge-from-i2c-address/183489/21 "2021-07-16T18:07:10Z")
Some of these may help, but isn’t in any particular order… About module naming: [https://forums.developer.nvidia.com/t/jetson-nano-board-setup/163668/6](https://forums.developer.nvidia.com/t/jetson-nano-board-setup/163668/6) Beware that the command “`uname -r`” is used by a kernel to find its modules, and that the result of this is from a combination of the base kernel version plus the `CONFIG_LOCALVERSION` (see the above URL). If you start with the original kernel version and configuration, then set `CONFIG_LOCALVERSION` to match the old kernel’s “`uname -r`”, then the original modules and module location will keep working. The location is: `/lib/modules/$(uname -r)/kernel` …and this is often forgotten and so a new kernel fails to find modules. A partial extension of the above URL, but aimed more at configuring: [https://forums.developer.nvidia.com/t/attempts-to-set-up-ecryptfs-and-fscrypt-failed-and-failed-and-failed/119083/2](https://forums.developer.nvidia.com/t/attempts-to-set-up-ecryptfs-and-fscrypt-failed-and-failed-and-failed/119083/2) A URL regarding kernel build, but with more device tree and kernel argument focus: [https://forums.developer.nvidia.com/t/about-kernel/77995/18](https://forums.developer.nvidia.com/t/about-kernel/77995/18) Just a recipe when compiling natively from the Jetson (there would be more environment setup for cross compile): ```auto # --- Setting Up: ------------------------------------------------------- # DO NOT BUILD AS ROOT/SUDO!!! You might need to install source code as root/sudo. mkdir -p "${HOME}/build/kernel" mkdir -p "${HOME}/build/modules" mkdir -p "${HOME}/build/firmware" export TOP="/usr/src/sources/kernel/kernel-4.9" export TEGRA_KERNEL_OUT="${HOME}/build/kernel" export TEGRA_MODULES_OUT="${HOME}/build/modules" export TEGRA_FIRMWARE_OUT="${HOME}/build/firmware" export TEGRA_BUILD="${HOME}/build" # --- Notes: ------------------------------------------------------------ # It is assumed kernel source is at "/usr/src/sources/kernel/kernel-4.9". # Check if you have 6 CPU cores, e.g., via "htop". # If you are missing cores, then experiment with "sudo nvpmodel -m 0, -m 1, and -m 2". # Perhaps use "htop" to see core counts. # Using "-j 6" in hints below because of assumption of 6 cores. # ----------------------------------------------------------------------- # Compile commands start in $TOP, thus: cd $TOP # Do not forget to provide a starting configuration. Probably copy of "/proc/config.gz", # to $TEGRA_KERNEL_OUT, but also perhaps via: make O=$TEGRA_KERNEL_OUT nconfig # If building the kernel Image: make -j 6 O=$TEGRA_KERNEL_OUT Image # If you did not build Image, but are building modules: make -j 6 O=$TEGRA_KERNEL_OUT modules_prepare # To build modules: make -j 6 O=$TEGRA_KERNEL_OUT modules # To build device tree content: make -j 6 O=$TEGRA_KERNEL_OUT dtbs # To put modules in "$TEGRA_MODULES_OUT": make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT # To put firmware and device trees in "$TEGRA_FIRMWARE_OUT": make -j 6 O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT ``` In the above, when run on a Jetson, it assumes source exists at “`TOP`”, and in this case “`/usr/src/sources/kernel/kernel-4.9`” was chosen. You could change this if source is somewhere else. Also, several targets which you probably won’t use are shown, e.g., a lot of people won’t build firmware, and if reusing the old modules, then probably won’t rebuild all modules. More typical is to build a single module. Official documents are for cross compile and are a variation on the above “recipe”. Advice: If you start with the original kernel config, and only add config, then you probably don’t need to rebuild modules. However, there are times when you remove features which were non-module format, and this could be a “more invasive” change (e.g., adding or removing the ability to use swap is invasive), and you will want to rebuild everything…kernel and modules, but not firmware. Advice: You will see flashing as a method of installing a new kernel. This is usually unnecessary (assuming you have not burned security fuses), and the kernel in “`/boot`” (the “`Image`” file) only needs to change if you’ve changed an integrated feature. Adding or removing a module allows you to not bother changing the “`Image`” file when the “`uname -r`” remains constant. You can leave the original “`Image`” file in place, add a new one with a modified name (e.g., “`Image-custom1`”), and add a new entry to “`extlinux.conf`” and pick the new kernel via serial console…if it were to fail, you simply use the original entry; if it succeeds, then you can modify “`extlinux.conf`” to make this the default while still leaving the “safe original” in place for picking with serial console should the need arise. --- _[View the full topic](https://forums.developer.nvidia.com/t/no-acknowledge-from-i2c-address/183489)._