Moving Linux kernel to 4.9

[ktb]

Those files look OK to me.

How about the output of sudo /opt/vc/bin/vcdbg log msg ?

Tips -
1.) You shouldn't need to have the i2c-bcm2708 (or i2c-bcm2835) and rtc-ds1307 modules listed in /etc/modules.
2.) You also shouldn't need to add the RTC device (echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device) in /etc/rc.local.

Something like the following should work in config.txt:

Code: Select all

# Uncomment this to enable the UPS PIco IR receiver
#dtoverlay=lirc-rpi:gpio_in_pin=18,gpio_in_pull=down

# Uncomment this to enable the UPS PIco RTC
#dtoverlay=i2c-rtc,ds1307

[Siewert308SW]

Those files look OK to me.

How about the output of sudo /opt/vc/bin/vcdbg log msg ?

Tips -
1.) You shouldn't need to have the i2c-bcm2708 (or i2c-bcm2835) and rtc-ds1307 modules listed in /etc/modules.
2.) You also shouldn't need to add the RTC device (echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device) in /etc/rc.local.

Something like the following should work in config.txt:

Code: Select all

# Uncomment this to enable the UPS PIco IR receiver
#dtoverlay=lirc-rpi:gpio_in_pin=18,gpio_in_pull=down

# Uncomment this to enable the UPS PIco RTC
#dtoverlay=i2c-rtc,ds1307

I commented out those lines you mentioned in /etc/modules and /etc/rc.local
Added dtoverlay as mentioned but didn't do the trick.
Deamon is running but can't connect the UPS while the the i2cdetect is correct.

as for sudo /opt/vc/bin/vcdbg log msg:

Code: Select all

Unable to determine the value of __LOG_START
Unable to read logging_header from 0x00000000

At the moment flashing a fresh copy of Jessie lite
And will start from scratch to see if the above thoughts has some effect.

[ktb]

Please comment out "gpu_mem=8" in your config.txt or logging won't work.

[Siewert308SW]

Please comment out "gpu_mem=8" in your config.txt or logging won't work.

Thx for the tip.
Will do in a moment, don't have a spare pi3 while the one i have is doing a full upgrade from scratch,
When done i will put the original sdcard back in and give you the output.

[Siewert308SW]

Hereby the output for sudo /opt/vc/bin/vcdbg log msg for the working kernel and non working kernel.

4.4.50-v7+ armv7l

Code: Select all

001065.655: HDMI:EDID error reading EDID block 0 attempt 0
001066.918: HDMI:EDID error reading EDID block 0 attempt 1
001068.176: HDMI:EDID error reading EDID block 0 attempt 2
001069.434: HDMI:EDID error reading EDID block 0 attempt 3
001070.693: HDMI:EDID error reading EDID block 0 attempt 4
001071.951: HDMI:EDID error reading EDID block 0 attempt 5
001073.208: HDMI:EDID error reading EDID block 0 attempt 6
001074.465: HDMI:EDID error reading EDID block 0 attempt 7
001075.723: HDMI:EDID error reading EDID block 0 attempt 8
001076.980: HDMI:EDID error reading EDID block 0 attempt 9
001078.002: HDMI:EDID giving up on reading EDID block 0
001092.658: HDMI:Setting property pixel encoding to Default
001092.678: HDMI:Setting property pixel clock type to PAL
001092.697: HDMI:Setting property content type flag to No data
001092.717: HDMI:Setting property fuzzy format match to enabled
001336.494: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001336.530: hdmi: Setting state machine clock to 163682864 Hz
001337.583: hdmi: requested state machine clock @ 163682864 Hz, measured as 163683000 Hz
001337.599: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading EDID<<<<<<<<<<<<<
001337.896: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001339.156: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001340.417: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001341.678: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001342.939: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001344.200: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001345.461: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001346.722: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001347.983: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001349.244: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001350.268: hdmi: HDMI:EDID giving up on reading EDID block 0
001350.299: hdmi: HDMI: No lookup table for resolution group 0
001350.318: hdmi: HDMI: hotplug attached with DVI support
001350.348: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001350.639: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001351.901: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001353.165: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001354.428: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001355.691: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001356.954: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001358.217: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001359.480: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001360.743: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001362.006: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001363.032: hdmi: HDMI:EDID giving up on reading EDID block 0
001365.378: hdmi: HDMI: hotplug deassert
001365.391: hdmi: HDMI: HDMI is currently off
001365.403: hdmi: HDMI: changing mode to unplugged
001365.427: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001368.476: *** Restart logging
001370.341: Read command line from file 'cmdline.txt'
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=c0ac452a-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=20 rootwait
001628.563: Loading 'kernel7.img' to 0x8000 size 0x409fd8
001629.523: No kernel trailer (run mkknlimg to fix) - assuming DT-capable
001637.487: Loading 'bcm2710-rpi-3-b.dtb' to 0x411fd8 size 0x3e78
001737.854: dtparam: i2c_arm=on
002834.314: Device tree loaded to 0x2effbc00 (size 0x4377)
002839.836: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
003598.516: vchiq_core: vchiq_init_state: slot_zero = 0xfac80000, is_master = 1
003602.780: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
003604.043: cec: setting callback (0x3DCA9D08)

4.9.11-v7+ armv7l

Code: Select all

001065.631: HDMI:EDID error reading EDID block 0 attempt 0
001066.894: HDMI:EDID error reading EDID block 0 attempt 1
001068.152: HDMI:EDID error reading EDID block 0 attempt 2
001069.410: HDMI:EDID error reading EDID block 0 attempt 3
001070.668: HDMI:EDID error reading EDID block 0 attempt 4
001071.926: HDMI:EDID error reading EDID block 0 attempt 5
001073.184: HDMI:EDID error reading EDID block 0 attempt 6
001074.442: HDMI:EDID error reading EDID block 0 attempt 7
001075.699: HDMI:EDID error reading EDID block 0 attempt 8
001076.957: HDMI:EDID error reading EDID block 0 attempt 9
001077.978: HDMI:EDID giving up on reading EDID block 0
001092.632: HDMI:Setting property pixel encoding to Default
001092.652: HDMI:Setting property pixel clock type to PAL
001092.671: HDMI:Setting property content type flag to No data
001092.691: HDMI:Setting property fuzzy format match to enabled
001336.472: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001336.508: hdmi: Setting state machine clock to 163682864 Hz
001337.561: hdmi: requested state machine clock @ 163682864 Hz, measured as 163683000 Hz
001337.577: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading EDID<<<<<<<<<<<<<
001337.874: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001339.134: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001340.395: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001341.656: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001342.917: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001344.178: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001345.439: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001346.700: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001347.961: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001349.222: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001350.246: hdmi: HDMI:EDID giving up on reading EDID block 0
001350.278: hdmi: HDMI: No lookup table for resolution group 0
001350.296: hdmi: HDMI: hotplug attached with DVI support
001350.327: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001350.617: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001351.879: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001353.143: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001354.406: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001355.669: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001356.932: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001358.195: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001359.458: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001360.721: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001361.984: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001363.010: hdmi: HDMI:EDID giving up on reading EDID block 0
001365.356: hdmi: HDMI: hotplug deassert
001365.369: hdmi: HDMI: HDMI is currently off
001365.381: hdmi: HDMI: changing mode to unplugged
001365.405: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001368.453: *** Restart logging
001370.270: Read command line from file 'cmdline.txt'
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=c0ac452a-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=20 rootwait
001653.010: Loading 'kernel7.img' to 0x8000 size 0x45cec8
001653.970: No kernel trailer (run mkknlimg to fix) - assuming DT-capable
001660.617: Loading 'bcm2710-rpi-3-b.dtb' to 0x464ec8 size 0x4262
001771.147: dtparam: i2c_arm=on
002884.691: Device tree loaded to 0x2effb800 (size 0x4769)
002890.198: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
004402.257: vchiq_core: vchiq_init_state: slot_zero = 0xfa980000, is_master = 1
004406.402: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
004407.652: cec: setting callback (0x3DCA9D08)

[ktb]

Hmmm. I don't see anything that is clearly wrong there. The Device Tree stuff gets loaded to different locations, but I don't think that's necessarily a problem? I suppose you could dig into the picofssd code to see if there is a problem there or if it's producing any errors, but why bother if i2cget/i2cset aren't working.

If it will help, I could take out my UPS PIco HV 1.0 and set it up on my Pi2B to see if that still works with the 4.9.x kernel. I haven't used the UPS PIco or Pi2B in a long time and I'm not sure what all the differences might be between our different hardware versions.

Perhaps the RP engineers have some ideas.

[notro]

There's a fallback option:
config.txt

Code: Select all

dtoverlay=i2c-bcm2708

The i2c-bcm2835 driver has some debugging support to aid in tracking down issues. See this commit: i2c: bcm2835: Add debug support

[Siewert308SW]

Hmmm. I don't see anything that is clearly wrong there. The Device Tree stuff gets loaded to different locations, but I don't think that's necessarily a problem? I suppose you could dig into the picofssd code to see if there is a problem there or if it's producing any errors, but why bother if i2cget/i2cset aren't working.

If it will help, I could take out my UPS PIco HV 1.0 and set it up on my Pi2B to see if that still works with the 4.9.x kernel. I haven't used the UPS PIco or Pi2B in a long time and I'm not sure what all the differences might be between our different hardware versions.

Perhaps the RP engineers have some ideas.

My thought also, been flashing, trail and error entire day.
i2c is open as i can see the tables and call ports and deamon is running acording the led on the UPS which should be blinking fast and it doesn't without the deamon.
Clean install with only the necessary packages as per install manual is the closest i can get.
My best guess but can't find any evidence something has changed in the kernel which doesn't correspond with the ups firmware and there for those weird 0xff readings instead of normal byte reading.
The dev of the pico is going to look into it and hope to have a answer soon.

Feel free to try, but don't think it will help or maybe a little.
pcb and firmware are different and miles apart.

There's a fallback option:
config.txt

Code: Select all

dtoverlay=i2c-bcm2708

The i2c-bcm2835 driver has some debugging support to aid in tracking down issues. See this commit: i2c: bcm2835: Add debug support

Doesn't work, if i use it then rebooting hangs at eth in the booting process

[cjan]

wifi dongle 8192cu module did not blinking.

indicator led light did not blinking.
and, after hours become drop & reconnect repeatedly.

[ktb]

Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708

I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait until everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.

[Siewert308SW]

Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708

I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait till everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.

Thx for the feedback and reproducing.
It's indeed almost the same issue but the main difference is your i2cdetect is starting to fail while mine continues to work.
And reading i2c with i2cget 0x69 xxx only give 0xff readings while it should be a byte reading.

[ktb]

Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708

I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait till everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.

Thx for the feedback and reproducing.
It's indeed almost the same issue but the main difference is your i2cdetect is starting to fail while mine continues to work.
And reading i2c with i2cget 0x69 xxx only give 0xff readings while it should be a byte reading.

Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget and UPSR resets make no difference whatsoever.

[Siewert308SW]

Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.

I understand, but now the million dollar question
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?

[ktb]

Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.

I understand, but now the million dollar question
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?

Well, there have been I2C changes in the kernel and it makes sense that the problems are caused by the combination of kernel and UPS firmware. It's difficult for me to pin blame solely on either one. The UPS firmware has always been a black box as far as I know. I also don't have any other I2C devices I can test against the kernel, so that makes it tougher to test that angle. EDIT: IIRC, the official touch display actually works over I2C because Eric had problems with using DSI.

[Siewert308SW]

Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.

I understand, but now the million dollar question
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?

Well, there have been I2C changes in the kernel and it makes sense that the problems are caused by the combination of kernel and UPS firmware. It's difficult for me to pin blame solely on either one. The UPS firmware has always been a black box as far as I know. I also don't have any other I2C devices I can test against the kernel, so that makes it tougher to test that angle.

I see and no worries, appreciate your effort and confirming.
I can't test other i2c devices and don't have the knowledge to debug the ups and kernel combination.
Lets hope someone else can fix it or until the ups dev ran into the same issue as it will happen in the near future.
Until then i'll have to stick to 4.4.50 #bummer

thx in advanced

[PhilE]

I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.

[Siewert308SW]

I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.

Will do, hope tomorrow if i'm home early otherwise it will be friday

[ktb]

I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.

Hi PhilE,

Here you go -- http://pastebin.com/AJjsJ82h

Thank you.

[PhilE]

Thanks. It's interesting how the RTC driver (or the I2C subsystem on its behalf) keeps on repeating the same transaction, even though there's no obvious error. I've no idea yet why that is, but your trace takes us much closer to an answer.

[Siewert308SW]

I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.

Just a little bit earlier then expected.
But here are my findings.

Information on 4.4.50 PI3 in working condition:
Some screenshots while running 4.4.50 kernel on my Pi3.
On which everything is working as it should be.
When doing i2cget -y 1 0x69 0x26 i get a output of 0x24, in this case i read the current firmware version

System Info:

https://dl.dropboxusercontent.com/u/232 ... ebug_1.png


UPS HV3.0A Stack Plus:

https://dl.dropboxusercontent.com/u/232 ... ebug_2.png

i2cdetect -y 1 output

Code: Select all

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU 69 6a 6b 6c 6d 6e 6f
70: -- -- -- -- -- -- -- --

Next i went into /etc/modules and comment out all driver loads.
Only let i2c-dev untouched and added i2c_bcm2835.debug=3 to the cmdline.txt
Connected to the UPS by i2cget -y 1 0x69 0x26.
Output : http://pastebin.com/bJjGzBev

Information on 4.9.11 PI3 in non working condition:
Next i ran rpi-update and upgraded to 4.9.11-v7+ armv7l
Rebooted and and connected to the UPS by i2cget -y 1 0x69 0x26 i got a output of 0xff which should output 0x24
Output : http://pastebin.com/f9vXqqhn

i2cdetect -y 1 output on 4.9.11

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 69 6a 6b 6c 6d 6e 6f
70: -- -- -- -- -- -- -- --

edit: Just notice that after doing i2cget -y 1 0x69 0x26 it also wrote instead of reading.
After returning to 4.4.50 a saw it wrote 0xde to the ups, weird...

[ktb]

edit: Just notice that after doing i2cget -y 1 0x69 0x26 it also wrote instead of reading.
After returning to 4.4.50 a saw it wrote 0xde to the ups, weird...

Hmm... Very interesting.

It's also good to hear that the Sense HAT is working properly. I don't think the touch display uses the same i2c bus, but the display has been working well enough for me in general on 4.9.x.

[notro]

Trace events/points can also be used to debug i2c. One benefit is that it displays the content of the buffer.
I have nothing connected here, just showing what it looks like:

Code: Select all

$ echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable

$ i2cget -y 1 0x69 0x26
Error: Read failed

$ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 6/6   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          i2cget-792   [002] ....    64.249432: smbus_read: i2c-1 a=069 f=0000 c=26 BYTE_DATA
          i2cget-792   [002] ....    64.249445: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [26]
          i2cget-792   [002] ....    64.249448: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-792   [002] ....    64.249707: i2c_result: i2c-1 n=0 ret=-121
          i2cget-792   [002] ....    64.249711: smbus_reply: i2c-1 a=069 f=0000 c=26 BYTE_DATA l=1 [0a]
          i2cget-792   [002] ....    64.249714: smbus_result: i2c-1 a=069 f=0000 c=26 BYTE_DATA rd res=-121

# clear trace buffer
$ echo | sudo tee /sys/kernel/debug/tracing/trace

Refs:
https://linuxtv.org/wiki/index.php/Bus_ ... iffing#i2c
https://www.kernel.org/doc/Documentatio ... events.txt

[ktb]

Thank you very much, notro. I don't think it provides any further explanation of what's going wrong in this case, but that seems like a valuable feature. I was not aware of it.

Code: Select all

pi@raspberrypi:~ $ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 28/28   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          i2cget-2620  [003] .... 25755.444984: smbus_read: i2c-1 a=069 f=0000 c=0 BYTE_DATA
          i2cget-2620  [003] .... 25755.445006: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [00]
          i2cget-2620  [003] .... 25755.445010: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-2620  [003] .... 25755.445681: i2c_reply: i2c-1 #1 a=069 f=0001 l=1 [ff]
          i2cget-2620  [003] .... 25755.445687: i2c_result: i2c-1 n=2 ret=2
          i2cget-2620  [003] .... 25755.445693: smbus_reply: i2c-1 a=069 f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2620  [003] .... 25755.445697: smbus_result: i2c-1 a=069 f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2637  [003] .... 25825.097963: smbus_read: i2c-1 a=069 f=0000 c=0 BYTE_DATA
          i2cget-2637  [003] .... 25825.097984: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [00]
          i2cget-2637  [003] .... 25825.097989: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-2637  [003] .... 25825.098620: i2c_reply: i2c-1 #1 a=069 f=0001 l=1 [ff]
          i2cget-2637  [003] .... 25825.098629: i2c_result: i2c-1 n=2 ret=2
          i2cget-2637  [003] .... 25825.098636: smbus_reply: i2c-1 a=069 f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2637  [003] .... 25825.098640: smbus_result: i2c-1 a=069 f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2654  [002] .... 25991.176494: smbus_read: i2c-1 a=06b f=0000 c=0 BYTE_DATA
          i2cget-2654  [002] .... 25991.176515: i2c_write: i2c-1 #0 a=06b f=0000 l=1 [00]
          i2cget-2654  [002] .... 25991.176519: i2c_read: i2c-1 #1 a=06b f=0001 l=1
          i2cget-2654  [002] .... 25991.177173: i2c_reply: i2c-1 #1 a=06b f=0001 l=1 [ff]
          i2cget-2654  [002] .... 25991.177179: i2c_result: i2c-1 n=2 ret=2
          i2cget-2654  [002] .... 25991.177185: smbus_reply: i2c-1 a=06b f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2654  [002] .... 25991.177189: smbus_result: i2c-1 a=06b f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2662  [002] .... 25994.847091: smbus_read: i2c-1 a=06b f=0000 c=1 BYTE_DATA
          i2cget-2662  [002] .... 25994.847111: i2c_write: i2c-1 #0 a=06b f=0000 l=1 [01]
          i2cget-2662  [002] .... 25994.847116: i2c_read: i2c-1 #1 a=06b f=0001 l=1
          i2cget-2662  [002] .... 25994.847750: i2c_reply: i2c-1 #1 a=06b f=0001 l=1 [ff]
          i2cget-2662  [002] .... 25994.847757: i2c_result: i2c-1 n=2 ret=2
          i2cget-2662  [002] .... 25994.847762: smbus_reply: i2c-1 a=06b f=0000 c=1 BYTE_DATA l=1 [ff]
          i2cget-2662  [002] .... 25994.847767: smbus_result: i2c-1 a=06b f=0000 c=1 BYTE_DATA rd res=0

[PhilE]

The debug logs from the driver don't include enough information to distinguish success from failure, so notro's tracing method looks like a better bet.

Put this in a file called trace:

Code: Select all

echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable
sudo cat /sys/kernel/debug/tracing/trace

Running ". trace" will then enable tracing and print out the current contents.

@ktb Can you enable tracing then read from the RTC?

Code: Select all

. trace
sudo hwclock -r
. trace > trace.txt

[Siewert308SW]

The debug logs from the driver don't include enough information to distinguish success from failure, so notro's tracing method looks like a better bet.

Put this in a file called trace:

Code: Select all

echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable
sudo cat /sys/kernel/debug/tracing/trace

Running ". trace" will then enable tracing and print out the current contents.

@ktb Can you enable tracing then read from the RTC?

Code: Select all

. trace
sudo hwclock -r
. trace > trace.txt

So even my log posted earlier doesn't help?

Should we do the trace without the modules loaded and i2c_bcm2835.debug=3 enabled?