I2C-1 not accessible

[Neil Cobbett]

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
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr6=/lib/firmware/BB-BONE-AUDI-01-00A0.dtbo
uboot_overlay_addr7=/lib/firmware/BB-PWM2-00A0.dtbo
uboot_overlay_addr8=/lib/firmware/BB-I2C1-00A0.dtbo

###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.9.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.9.x-ti, 4.14.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

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]
kernel:[4.14.49-ti-r54]
nodejs:[v6.14.3]
device-tree-override:[dtb=am335x-boneblack-wireless.dtb]
uboot_overlay_options:[enable_uboot_overlays=1]
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]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20180619.0-0rcnee0~stretch+20180619]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[roboticscape]:[0.4.4-git20180608.0-0rcnee0~stretch+20180609]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpi
o pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[    1.055764] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[    1.057036] gpio-of-helper ocp:cape-universal: ready
END

debian@beaglebone:~$ uname -a
Linux beaglebone 4.14.49-ti-r54 #1 SMP PREEMPT Fri Jun 15 22:14:13 UTC 2018 armv7l GNU/Linux

[Robert Nelson]

On Wed, Jun 20, 2018 at 11:35 AM, Neil Cobbett <neil.c...@gmail.com> wrote:
> 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,

--
Robert Nelson
https://rcn-ee.com/

[Neil Cobbett]

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

[Robert Nelson]

On Wed, Jun 20, 2018 at 11:50 AM, Neil Cobbett <neil.c...@gmail.com> wrote:
> 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?

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..

[Neil Cobbett]

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

[Robert Nelson]

On Wed, Jun 20, 2018 at 11:59 AM, Neil Cobbett <neil.c...@gmail.com> wrote:
> 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:

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

[Neil Cobbett]

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

   

60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --  

70: -- -- -- -- -- -- -- --         

[Robert Nelson]

On Wed, Jun 20, 2018 at 12:20 PM, Neil Cobbett <neil.c...@gmail.com> wrote:
> 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

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..