nelgau has quit [Remote host closed the connection]
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
peeps has quit [Read error: Connection reset by peer]
peeps[zen] has joined #litex
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
FabM has quit [Ping timeout: 245 seconds]
<Peanut>
Is there a way, from Linux running on the target FPGA, to see all the devices/CSR? I have added a i2c driver to the butterstick platform and linux-on-vexriscv build. I can see that it gets added to the .dts, but the i2cdetect in the Linux userspace doesn't seem to detect it.
<Peanut>
Also missing is /dev/i2c/
<somlo>
Peanut: from a brute force perspective, you can always map physical memory to userspace (e.g., using `mmap()`) and then access it at your leisure (since CSRs are memory mapped)
<Peanut>
Good point - and the .dts shows where they are in memory space, I guess.
<somlo>
alternatively, you more likely want a linux device driver for your particular device to do that on your behalf (and that's how you end up with things like /dev/i2c/... to use your example)
<Peanut>
Yes, what I'm trying to find out is why the kernel hasn't picked up that there is an i2c device to use, as it is now listed in the .dtb.
<somlo>
yeah, .dts tells the booting kernel where to look for which devices, and initialize them if it knows how (if the "compat" string matches some kernel specific device driver, when it all boils down to it)
<Peanut>
The kernel does have the driver "[19.671763] i2c_dev: i2c /dev entries driver"
<Peanut>
I see.. the .dts says "compatible = "litex,i2c", (...), status = "okay", which sounds somewhat promissing.
<Wolfvak>
can you post the .dts in a pastebin? there's a chance the device driver is simply not enabled in the kernel config, too
<somlo>
not familiar with i2c, but if it were me I'd recompile the kernel with added `pr_warn("Got Here\n")` statements in the i2c driver probe function, and see if any of it gets executed, and where it fails :)
<somlo>
there are more elegant ways to debug things, but I'm old :D
<somlo>
right, also what Wolfvak said :)
<somlo>
check your kernel .config and make sure you're enabling the i2c driver...
<Wolfvak>
also, the way you say it sounds like you have set up an I2C bus driver, but not an I2C device driver
<Peanut>
I seem to have Wolfvak: Regarding your last comment: I'm trying to make the FPGA act as an I2C controller, and don't have a particular device driver in mind yet (i2cget will do for now). Does that make sense?
<Wolfvak>
looks right, just make sure the driver is enabled in the config and it should work, you can always check /sys/class/i2c if needed though
<Peanut>
/sys/class/i2c-dev is empty, and so is /sys/class/i2c-adapter
<Wolfvak>
sounds like the driver is not compiled in
<Wolfvak>
you can also check /sys/firmware iirc, you can look for the exact devicetree node there and see if there's any driver associated with it
<Peanut>
/sys/firmware/devicetree/base/soc/i2c@f0003800 exists - put that's probably just the unpacked contents of the .dtb. Good to see that the kernel got the right .dtb at least.
<Peanut>
I've just rebuilt the same thing for the OrangeCrab, which does come with native i2c - it bomes up with the same devicetree fragment, just at a slightly different address, all the other options are the same. And on the OrangeCrab, the i2c is perfectly usable. Interesting.
<Peanut>
No wait, there's differences - I built the ButterStick buildroot/kernel myself, whereas the OrangeCrab came from the LiteX Github repositories.
<Peanut>
So I'm going to see if I can compare the two - but that's for tomorrow, goodnight and thanks!
<Peanut>
Oh, and I just found the kernel config file: "CONFIG_I2C=y, CONFIG_I2C_LITEX=y, CONFIG_I2C_CHARDEV=y"