I2C-1 not accessible

GoogleGroups
1

HI,

I have an issue gaining access to I2C-1 where I have a RTC battery backed clock mapped on a purpose built cape board. It worked fine in 3.8 kernel but is broken in 4.9 and 4.14 kernels.

There were issues previously in 3.8 with the mappings /naming of the I2C:
i.e.
I2C-0 = bus 0
I2C-1 = bus 2
I2C-2 - bus 1

but with a bit of investigation work using i2cdetect I found my RTC chip (A ds3231).

running:
echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-2/new_device

It mapped fine and I saw it come up as a device at /dev/rtc1

NOW MY CURRENT PROBLEM with I2C-1 with 4.14 kernel is ….

I map the dtbo file in uEnv.txt:
uboot_overlay_addr8=/lib/firmware/BB-I2C1-00A0.dtbo

With a vanilla device tree, I see all three I2C devices present (using i2cdetect -l). BUT If I scan each one in turn to see what devices are present, it works fine for bus 0 and bus 2 but stalls querying bus 1. Bus 1 outputs data very slowly (takes over a minute to complete rather than seconds) as if it is being interfered with or has some sort of problem. Eventually when it complete, it also doesn’t find the RTC chip.

Further, if I add other dtbo’s to uEnv.txt i.e.
uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo

Then the I2C-1 never gets loaded on boot and I just end up with just I2C-0 and I2C-2.

Somethings not right but I can’t figure out what… any pointers?

I’ve tried building the latest dts files from scratch but no change!

EXTRA Info:

debian@beaglebone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.14.49-ti-r54
#uuid=
dtb=am335x-boneblack-wireless.dtb

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1

2

HI,

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[31292bce1d4b35b497cc7a013d6d57e7e1f4f5c4]
]eprom:[A335BNLTBBWG3997�O
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Image 2018-06-17]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2018.03-00002-gac9cce7c6a]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2017.09-00002-g0f3f1c7907]:[location: dd MBR]

u-boot in the eMMC is blocking overlays from working properly..

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

kernel:[4.14.49-ti-r54]
nodejs:[v6.14.3]
device-tree-override:[dtb=am335x-boneblack-wireless.dtb]

With u-boot fixed above, this define in /boot/uEnv.txt is no longer
needed (and will actually disable/break the overlays).

Regards,

3

HI Robert,

That looks a bit of a scary command:

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Will this damage the boot loader? So the solution is to do a low level write to the onboard flash? I’m currently running on the SD card but plan to flash it to onboard flash once I get the system stable.

I’ll give it a go but from previous issues I am uneasy using dd. Is there a way to upgrade uboot loader instead?

Neil

4

Hi Neil,

It'll remove the first 10MB of data from the eMMC, which will remove
"U-Boot 2017.09-00002-g0f3f1c7907" which doesn't support u-boot
overlays..

Once you have your microSD working properly, you can still flash it to
the eMMC, in which case the flasher will copy the version of u-boot
from your microSD..

Regards,

5

Hi Robert,

I did what you said then ‘sudo reboot’ but I have not observed a difference. With UARTs enabled I get no i2c-1. With uarts disabled I get all three i2c buses but bus 1 takes ages to read:

debian@beaglebone:~$ i2cdetect -l
i2c-1 i2c OMAP I2C adapter I2C adapter
i2c-2 i2c OMAP I2C adapter I2C adapter
i2c-0 i2c OMAP I2C adapter I2C adapter
debian@beaglebone:~$ i2cdetect -y -r 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- UU – -- – -- – -- – -- – -- –
30: – -- – -- 34 – -- – -- – -- – -- – -- –
40: – -- – -- – -- – -- – -- – -- – -- – --
50: UU – -- – -- – -- – -- – -- – -- – -- –
60: – -- – -- – -- – -- – -- – -- – -- – --
70: 70 – -- – -- – -- –
debian@beaglebone:~$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – 1b – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- UU UU UU UU – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – --
debian@beaglebone:~$ i2cdetect -y -r 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – --

6

Hi Neil,

Oh looking back at your first message, you went too far with the addr's...

<quote>
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/BB-BONE-AUDI-01-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/BB-PWM2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr8=/lib/firmware/BB-I2C1-00A0.dtbo]
</quote>

uboot_overlay_addr8 doesn't exist..

You can use addr0->addr3, especially if you don't have an eeprom'ed
enabled cape plugged in..

uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-BONE-AUDI-01-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-PWM2-00A0.dtbo
uboot_overlay_addr4=/lib/firmware/BB-I2C1-00A0.dtbo

I've also seen i2c1 being slow..

Try: BB-I2C1-FAST-00A0.dtbo

Regards,

7

Hi Robert,

Yes, that fixed it!

Just to clarify a point… How many dtbo’s can you have in uEnv? I write my own and I could combine some into a single dtbo. I wonder if it is better to write one single uber dtbo for the board I have designed or stick with multiple stock dtbos found in /lib/firmware

Neil

debian@beaglebone:~$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – 1b – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- UU UU UU UU – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – --
debian@beaglebone:~$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – 1b – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- UU UU UU UU – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – --
debian@beaglebone:~$ i2cdetect -y -r 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- 68 – -- – -- – -- –
70: – -- – -- – -- – --

8

Via our docs, 8 or so.. There's a few in their for when we first
tested it for backwards sake, but if you look at the serial log, every
additional one add's a small time delay..

If you've spun an adapter board, it's best to just combine them as one..

Regards,