I2C issues with 5.4 + TC358743 #3602
Comments
|
@6by9 I'm sorry to call you directly, but you may be interested in this issue. However, I'm not sure if this is related to the tc358743 driver, because somehow it affected the MMC card driver as well. If you need more logs, I will try to provide them to you as soon as possible. |
|
Please provide your full configuration from config.txt. 5.4 has reworked i2c-0 to use the i2c-mux-pinctrl module to switch it between GPIOs 0&1, and whichever GPIOs the display/camera connector are attached to (either 28&29, or 44&45 dependent on variant). Any userspace messing with pinmuxing for i2c-0 should be avoided. i2c-0 is always GPIOs 0&1. i2c-10 is the camera/display. We've also had a fairly significant update to the bcm2835-unicam driver as part of the work for libcamera, but that seems sound. I'll have a look to see if there is anything obvious using standard v4l2-ctl commands. MMC and the firmware blocked warnings generally mean you've managed to kill the firmware, typically a memory trample somehow. |
|
It looks like my B101 board has died - it is recognised fine, set EDID and timings fine, but it doesn't produce any output data with either 5.4.38 or 4.19.118. |
|
OK, working fine with v4l2-ctl and yavta on a CM3L with B102, with kernel 5.4.35 and firmware 688a8f8f3d84e788f07f53c93693e1705f68c407 (rpi-update 8d64ec70 - top of tree today). More information required, particularly the source resolution and frame rate, format chosen from the B101, and what processing you're doing. I have a suspicion that it may be a firmware change that is the problem, not the kernel. There were a few changes to the video_encoder and ISP components relatively recently. |
|
config.txt: The last line does not affect the presence of the problem, I added it out of desperation when trying to understand what is happening. If you delete it, the problem persists.
I tried to simplify the way to reproduce the problem. The initial info about the launch of two times in a row, quite correct, the error appears upon termination of the read stream. I used yavta with EDID from your repository. Tried 720p/60Hz and 1080p/60Hz with UYVY - both resulted in a hang when pressing Ctrl+C.
By the way. This is not relevant, but as my users have found out, the B101 may burn due to an accidentally flown CSI cable. Both 4.x and 5.x kernels used firmware 688a8f8. I am using Arch Linux and using rpi-update will completely break the system. So I installed minimal Raspbian and used same config.txt exclude initramfs and i2c_arm lines. I also updated the system and executed Then I started moving through the firmware versions, as you said. The problem was successfully reproduced again. I assume you failed to reproduce it because you used CM3, not RPi4. Perhaps the model of the video capture board has some significance (but they seem to differ slightly from each other). |
|
1080p60 can't be supported using a B101. The B101 and B102 only differ in the number of CSI2 lanes that they present on the output connector, and the physical connector itself. I currently have no way to reproduce, so can't actually help.
|
Sorry, probably the KDE dialog is deceiving me and we are talking about 50 Hz. I forgot about this feature.
I found a 3B+ board and tried. The problem is not reproduced on it even without
I can't. I made a mistake in the initial diagnostics; immediately when the yavta process is interrupted, the core becomes inoperable.
Reproduced.
Not reproduced. Given the fact that I also tested on RPi 3B+ and the problem did not reproduce there, it seems that the problem is reproduced exactly and only on 5.4 and RPi4. The problem exists on two different B101 boards and several RPi4 users I contacted. What else could I do to help you debug this? |
|
You can try adding
You've got me fairly stumped if rpi-update e1050e9482 (4.19) works but 8d64ec7 (5.4) doesn't, and only on a Pi4. I'll have a dig through my parts boxes to see if I have another B101. Unfortunately there isn't a way to attach a B102 to a standard Pi - the 15pin to 22pin adapters are not reversible. The FFC cable on the one that was working is fairly kinked, so if nothing else I can try swapping the cables. It'd be nice to know what the cause of the failure was, but probably just static onto the CSI lines (shame it's that sensitive). |
|
@pelwell Any thoughts as to any setup that has changed only on Pi4 between 4.19 and 5.4 that would trip I2C this up? |
There's nothing specific to Pi 4 that I'm aware of that only affects I2C. It's probably worth making sure the EEPROM is up-to-date: |
Made with both kernels. It didn't affect anything. |
|
There are a lot of under-voltage warnings in your "i2c" log above. Either you are using a bad power supply or you are trying to power too much from your Pi. The Pi 4 includes under-voltage detection logic because there is a real possibility your Pi will malfunction in some way or other. Every silicon die is unique in its analogue electrical properties, causing the voltage tolerance to vary between devices, but as you reduce the voltage gradually eventually the weakest link in the chain will break. If you're lucky, one of the ARM cores will panic immediately, but the failure could be memory corruption that has time to propagate and perhaps even make it to persistent storage. You won't get support here until the under-voltage is resolved - it's not in your best interests. |
|
(Sorry for the deleted message, I attached the wrong log) @pelwell Okay, good point. I changed the power supply to a more powerful one and again successfully reproduced the problem, but this time without a single report of power problems. The terminal log is attached. Messages may differ slightly from launch to launch (as I've shown before), but it always starts with I2C messages. |
|
I understand that the problem looks strange. But it really exists not only for me, but for five other users that I know. All of them updated the kernel to 5.4 on RPi4 and all of them started having problems with B101 by I2C. I have excluded all previous assumptions about the nature of this bug. How else can I help fix it? |
|
I'm starting to think that I2C is just collateral damage caused by a firmware lockup. Your original reports says "an attempt to get an image from the tc358743 device twice in a row (reopen device file) results [in] I2C timeouts." Let's see if we can narrow down the cause of the failure by breaking the process down into a sequence of smaller steps.
|
|
The first message was not entirely accurate, I wrote. The problem does not occur on the second start, but when the first reading process is interrupted. That is, I run So I tried to follow your instructions:
|
|
The errors in 3 suggest that you have failed to disable the overlay in config.txt. You can verify that the overlay isn't present by looking in |
|
You'll need |
|
@pelwell I clarified that. The driver is not loaded and the overlay is missing: |
|
You're right - the overlay was written in a time when overlays modifying their own fragments was a bad idea, for which there is a workaround with an unfortunate side effect where you can't apply the overlay at runtime. You should be on a recent firmware with a 5.4 kernel, so I'll tweak the overlay to make it work in both scenarios. |
|
@6by9 Thanks! Correct me if I'm doing something wrong. I have never worked with I2C. |
|
@pelwell I didn't quite understand - are you going to make some kind of fix now and I will need to download it via rpi-update? Or is something else required of me? |
|
Can you test this updated overlay for me? It applies for me without any errors: |
|
@pelwell Sure. How do I do this? |
|
Save the code to a file - |
|
/dev/i2c-0 is GPIOs 0&1 (pins 28&29) would imply that you did still have the overlay loaded from config.txt, but we're beyond that now. |
|
[ corrected typo in the cp line above ] |
|
Use |
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. raspberrypi#3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
From when bringing up the driver, there was a check in the isr to ignore interrupts (claiming them handled) should the driver not be streaming. The VPU now will not register a camera driver if it finds a CSI2 node enabled in device tree, therefore this flawed check is redundant. #3602 Signed-off-by: Dave Stevenson <[email protected]>
Describe the bug
After updating the kernel from version 4.19.118 to 5.4.35 an attempt to get an image from the tc358743 device
twice in a row (reopen device file)results to I2C timeouts. In some cases, this leads to a hang (see log1), sometimes it causes errors when working with the MMC card and a reboot (see log2).UPD: The first message was not entirely accurate. The problem occur when the first reading process is interrupted. That is, I run yavta, press Ctrl+C and immediately got a dead kernel. I played around with yavta a bit and found out that the problem occurs either when closing /dev/video0 or when executing ioctl VIDIOC_STREAMOFF. I think the tc358743 driver is trying to command something over I2C, and everything stops working.
/UPD
To reproduce
Set up Auvidea B101 with kernel 4.4.35, run any capture software that supports DV-timings (https://github.com/pikvm/ustreamer, yavta, etc) and stop it.
Expected behaviour
No crashes when closing the device file
Actual behaviour
Subj
System
4B 1Gb
cat /etc/rpi-issue)?Arch Linux ARM (uses the kernel from this repo).
vcgencmd version)?uname -a)?Logs
Attached kernel log from tty.
Just I2C errors: log1.txt
MMC crash: log2.txt
The text was updated successfully, but these errors were encountered: