<Guest80>
Hi, I'm having trouble detecting an i2c device, does anyone have experience with getting i2c to work on beaglebone black?
<zmatt>
Guest80: to get useful feedback it'll help to provide more details
<zmatt>
like, what kind of device, what error are you getting, etc
<zmatt>
which pins (in general it's easiest to use i2c1 on P9.19 (scl) + P9.20 (sda) since that bus is configured by default)
<Guest80>
So I'm working with a BNO055 Magnetometer, and I've got it connected to pins 19 and 20 on p9, and when I run i2cdetect I don't see the address for the Magnetometer in either 1 or 2
<zmatt>
do you have adequate pull-ups (to 3.3V) on your bus?
<zmatt>
(e.g. a 4.7 kΩ pull-up on each of the two lines)
<Guest80>
I'm not really too sure, could I test to see if it works by connecting the resistors on the two lines?
<zmatt>
yep, one between SDA and 3.3V and one between SCL and 3.3V
<zmatt>
4.7 kΩ or whatever you have lying around that's the same order of magnitude
<zmatt>
unless the device already integrates pull-ups of course, then it's superfluous to have additional ones
<Guest80>
got it, I'll give it a shot
<zmatt>
also beware of i2cdetect. i2c is not a discoverable bus and i2cdetect is consequently not a reliable way to confirm the presence of a device, unless you know for a fact that i2cdetect is known to work for detecting this specific part
<zmatt>
it can also just confuse a part and not get any answer... I've ever encountered an i2c device that would get so confused by i2cdetect that it would subsequently refuse to reply to anything until power-cycled
<zmatt>
*even encountered
<zmatt>
anyway, I need to do shopping, I'll be back in a bit
Angel_Sosa has joined #beagle
Angel_Sosa1 has joined #beagle
Angel_Sosa has quit [Quit: Client closed]
Angel_Sosa1 is now known as Angel_Sosa
Guest54 has joined #beagle
<Guest80>
It doesn't look like it's detecting it
buzzmarshall has joined #beagle
<zmatt>
Guest80: what is "it" ?
<zmatt>
how are you trying to "detect" it?
Guest80 has quit [Quit: Client closed]
<zmatt>
also, are you using a particular breakout module for the BNO055 ? if so, which?
buzzmarshall has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
<Angel_Sosa>
Hello I have pasted a back trace that I am getting on several Beagle bones that started after an uprade. I have pasted the back trace on pastebin what is the next step? In advance I apologize if this is a low end question or appealing to the wrong forum?
<zmatt>
share the link to the paste?
<zmatt>
(i.e. the url of the page you get after clicking the "Create New Paste" button at the bottom of the form)
<zmatt>
looks like something to do with the TIDL firmware
<zmatt>
it's saying the EVE units are doing invalid accesses to some peripheral on the the L4_PER3 interconnect
<zmatt>
(the traceback is completely irrelevant)
<zmatt>
this will have no ill effect on the linux system, but obviously does indicate some sort of issue with TIDL... I've never worked with TIDL myself so I don't know if this causes any actual issues
<zmatt>
(if you don't care about TIDL then using a non-TIDL image or removing the TIDL firmware will solve this traceback)
<Angel_Sosa>
I will re- image with non-TIDL or remove the firmware which ever is easier and produces the cleanest results. How did you know it is referencing TIDL?
<zmatt>
because nothing else uses the EVEs
<zmatt>
certainly not on a fresh image
<Angel_Sosa>
Got it
<zmatt>
reimaging with non-TIDL is probably the easiest way to ensure all TIDL-related stuff is gone
<zmatt>
the non-TIDL image also has a more recent kernel than the TIDL one I think
<rcn-ee_>
main things done... Auto microSD resize (takes 1 reboot) and auto ssh regeneration on first boot.. I'm still configuring the defautl usb0/usb1 gadtets, but the new loader is way faster..
<Angel_Sosa>
I'll give that a try as well
<rcn-ee_>
please let me know how it works for you, i'm happy with the base, but i need to merge in all the udev rules, etc..
<rcn-ee_>
it's also 5.10.x based, so bugs might pop out.. ;)
<zmatt>
are all relevant drivers forward-ported to 5.10 ?
<rcn-ee_>
for the bbai, no... for the am335x, it's mostly mainline remoteproc...
<Angel_Sosa>
They may be but I would have to consult with the device tree. I have been working with a couple of boards for a while. I am getting deep into the boot process.Actually I would liket
<zmatt>
pinmux-helper/config-pin ?
<rcn-ee_>
Not installed, but i fixed the pinmux bug.. so config-pin will work again..
<rcn-ee_>
before it goes final, i do want to rename all the P8_xy names like you wanted..
<zmatt>
okay so this image comes with significant caveats :P
<zmatt>
ah the names of the pinmux nodes? yeah that's purely cosmetic of course
<rcn-ee_>
Login in 15seconds right now. ;) switch to bone 5.14.x i've seen 5-7 seconds. ;)
<rcn-ee_>
drop initrd, it's down to 2-3..
<zmatt>
why is initramfs-tools installed anyway? I don't think it's been needed for anything since kernel 4.9 or something like that?
<zmatt>
removing initramfs is generally one of the first things I do to speed up boot
<rcn-ee_>
it's needed for overlayroot users..(a systemd compabitle version of Read Only root..) the kernel shouldn't requre it anymore..
<rcn-ee_>
i know at one point, you pointed out we had a few linux-image* that depeneded on it, that should be long gone..
<zmatt>
yeah I noticed you removed the dependency
<zmatt>
prior to that I solved the problem by installing a dummy initramfs-tools package
<rcn-ee_>
Really, it was to make sure the *.dtbo's where in memory on bootup (v3.8.x -> v4.15.x) for kernel overlays, which are not used taht way..
<zmatt>
ah, kernel overlays... right, those were a thing that existed :D
<rcn-ee_>
i can't wait till someone tries 3.8.x on Bullseye, it's going to fail pretty bad, as 3.8.x doesn't come close anymore to the default requirements. ;)
<zmatt>
so uio-pruss didn't forward-port cleanly? what's the last kernel version does has it? I'll take a look to see if I can fix it
<zmatt>
iirc it's a pretty trivial driver
ikarso has joined #beagle
<rcn-ee_>
zmatt, after v5.4.x era..
<rcn-ee_>
i thought one of the GSOC students was working on pru on remoteproc.. Now that remoteproc is pretty much mainline i hope we coudl eventually use one default..
<rcn-ee_>
GSOC - "UIO" on remoteproc...
<zmatt>
I don't even know what that would mean
<zmatt>
remoteproc and uio are fundamentally different and deeply incompatible approaches
<zmatt>
remoteproc has the kernel in total control of pru, uio has userspace in total control of pru