No acknowledge from i2c address

I have a Xavier DK with an IMU attached to it, when the device is not connected it spams this message in dmesg and fills up the device space. currently, I am not able to push the fix to handle this in there a way to stop this ?
i have tried using ftput to edit the bus tree and change it okay to disabled but no luck.
For a quick fix I only need the logs to stop spaming as it stops the device from turning on and eats all the space

How about remove the IMU kernel driver.

hey @ShaneCCC ,
thank you for replying.How would that work ?

You need find the IMU driver from kernel source and remove it from the kernel config file to remove it.

I am not sure i follow,I am using the Linux smbus ,i2c-dev library

so in this directory
i can see these files “algos busses i2c-slave-eeprom.ko i2c-smbus.ko i2c-stub.ko”
is this it?

Not the bus driver. Can you check the kernel message to check if can figure out what slave device access the i2c

By running the command fdtget /boot/tegra194-p2888-0001-p2822-0000.dtb i2c1 -p

I dont see anything here ,how do I get the slave address

I think i found it
its 0x0703
this is used to initiliazie the connection
ioctl(mpu6050::file, I2C_SLAVE, addr)

Any help would be appreciated please.

Comment below in kernel config to build Image to try.


I am sorry,i don’t get what you are suggesting

For removing the mpu6050 driver you need to build customize kernel image for it.

Hey thanks for replying,
i dont think I can do it . I am constrained by a runtime environment .I am looking for a way to change this in run time

In the case of a driver which is integrated (the “=y” instead of “=m”), then I think rebuilding the kernel Image file might be mandatory to stop the feature. Most (all?) of the features for blacklisting a driver seem to require the form of a module. What you are seeing in the other replies is a need to rebuild the kernel, which in turn means needing to configure the kernel normally, and ending with removing just the CONFIG_IIO feature (thus the rest of the config is not changed).

You can always ask for information on kernel build, but the docs with a particular release show how to do this using cross compile from an Ubuntu 18.04 host PC. Once set up, after that initial setup, it becomes fairly trivial to build kernels. If you want to know what your current L4T release is (the o/s version the documents will be for), then see the output of “head -n 1 /etc/nv_tegra_release”. Then look for documents in that L4T release…see L4T releases here:

Basically there is a section on kernel customization. Once you can build a kernel Image, then I suggest you ask about installing the new Image file (there is more than one way to do this, some methods are more difficult than others).

Hey guys,
thanks for you reply.I couldn’t implement the method you were suggesting in time .So had to go with changes in code.
I am still not sure how would go about doing it if I or someone else need to do something similar

Learning to build and install new kernels isn’t as hard as it sounds, especially once the source code is set up and you’ve compiled once. In the Linux world though it is difficult to avoid kernel builds if you are trying to set up features or new hardware. It does initially take some patience, but if you plan to work with features in the kernel, then there won’t be much choice except to go through that initial learning curve.

1 Like

Hey @linuxdev ,
I agree with that,but unfortunately, I haven’t been able to find a proper guide on installing new kernels , and whenever I have asked on the forum I get vague descriptions.

I believe the l4t doc have guide how to build the kernel Image also how to update it.

Some of these may help, but isn’t in any particular order…

About module naming:

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:

A URL regarding kernel build, but with more device tree and kernel argument focus:

Just a recipe when compiling natively from the Jetson (there would be more environment setup for cross compile):

# --- 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":

# To put firmware and device trees in "$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.