Modprobe returns following: # modprobe i2c-dev modprobe: can't change directory to '/lib/modules': No such file or directory
Does anyone knows where could be the problem. I’m struggling with this for quite some time now, and I have been searching and trying different solutions, but with no success. I am relatively new to Linux, so any help would be much appreciated.
I’m a hardware guy, so my driver debug chops are lacking for sure, but…
Do you have the devices listed in the tree on your board: lcd, eeprom, rtc? If so, the easiest one to try is the rtc. If hwclock at the linux prompt works, your I2C bus is working. A line similar to this:
[ 1.963425] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
should show up in your kernel boot spew if the rtc driver is installed and finding the rtc device.
You might also try setting the kernel message log level to debug and see if there’s any additional information in the spew.
I’m not familiar with the Mercury SoM, but is your board close enough to the default configuration you could load a demo kernel, and root fs for that board, keeping your FPGA load and device tree? This might help determine whether the problem is FPGA/device tree or kernel/driver.
Actually, I have tried to add another driver file name in device tree. As you can see from my first post, find command did found designware driver, but named i2c_designware. In device tree it is says designware-i2c. So adding new compatible driver name did load the driver now. I get i2c-0 in /dev/. I’m still not clear why is this name automatically generated.
But, as you suggested, I’m still not able to get rtc working: [ 1.165974] rtc-ds1307: probe of 0-0068 failed with error -5
And weird thing is that RTC line is just before this: [ 1.171694] i2c /dev entries driver
I’ve again tried i2ctools, it scans but doesn’t detect any devices (and skips devices declared in device tree). When I checked the bus with oscilloscope, I didn’t record any activity during scan. And scan is finished instantly.
I will try your other recommendations and let you know.
Hmmm… my device tree has the compatible line compatible = "snps,designware-i2c";
as well, and I don’t have issues. I’m running kernel 4.4 from linux-fpga in altera-opensource on github. Perhaps the driver in 4.7 has changed the compatible name? You can check the driver source in the kernel tree and see.
U-boot has I2C tools as well (if they’re compiled in) which you can use to see if the bus is active at all.
Hold down a key during boot from power-up or reset, and at the u-boot prompt enter help to see if there are I2C tools built-in. In the command list you should see a line that looks like this:
i2c - I2C sub-system
If it’s there, enter i2c help for a list of commands for the I2C subsystem. If you try i2c probe it will list the I2C devices it can reach.
Essentially it sends a read to all the 7 bit I2C addresses and looks for ack/nack from each. Those with an ack get listed. It’s not perfect, as i have a device on my board that it doesn’t see, even though the device is working fine. It will, however talk to the device if I use the i2c md or i2c mw commands.
Try reading from the rtc device and see if you can get a response, that should at least eliminate board & device problems.
I have tried I2C tools from U-boot, probing and reading from specific device - no results.
Maybe I need to enable something extra in I2C controller during boot? I had to do similar thing for Ethernet controller in u-boot script, but this was to enable external PHY through gpio:
If you know the device is there, and should be working, it’s probably a pre-loader issue if u-boot can’t find it. Do you see scl/sda toggling with a scope when you try probing with u-boot? If not, it’s almost certainly a pre-loader issue. Make sure the pre-loader is generated with the output from your design, and that your BSEL pins are pointing to the right place to get it.
I have played around with u-boot, and noticed that I2C was held in reset. All I2C registers were set to 0.
Then I manually de-asserted it, and got good values in registers. But still after I2C probing there was nothing on oscilloscope.
In the meantime you posted reply with pre-loader issue, and after re-compiling the pre-loader, now I can see transmission on scope, as well as:
So, to sum up: At first I had my system running without I2C enabled in Qsys, and later I enabled it. I did generate new device tree, but left the old pre-loader, which caused all the problems.