I’ve been trying to get this issue to surface on our MangOH Red with no luck so far. I’m going to keep it running and see what happens. I had a theory that linked this issue to my host computer but unfortunately that contradicts my findings this morning.
Do you have any ideas in terms of anything that could trigger this problem? In terms of deviation from the MangOH Red reference design, our board has the following changes:
Removed the wm8944 audio codec
Removed the pca954x i2c hub
Removed the sx150x GPIO expander
Removed the USB hub
Removed the SPI over USB bridge
Kernel modules modified to use i2c bus i2c-0 for everything
Removed code that probes for the wm8944
SD card detection GPIO pin moved (with corresponding changes in Yocto)
(Unrelated to hardware change) Enabled charging in an attempt to use the ltc2942
I’ve also put together a small repository to show some of these changes:
Performed another test here to try and eliminate the host PC as a factor. Booted the device with just battery power and connected my PC over micro USB exactly 30 seconds after boot. All of the Bus still busy errors occur within the boot time range of 1 to 17 seconds (see here https://gist.github.com/nvandoorn/e1a9495a94ea06101de484c7598a2412). Based on this, I don’t believe the host PC is a factor here (which unfortunately contradicts my initial hypothesis).
Wanted to take a moment and report where we are at with this issue. After weeks of debugging, it seems this issue is a result of something in our hardware.
For everyone’s reference here’s what we discovered:
We had not included the I2C hub in our electrical design. We have now included the hub and have ALL devices connected to the I2C hub and a single data line going back to the WP8548. This resolved our ‘bus busy’ problem at boot.
We have found one unit so far (out of five) that has had a ‘bus busy’ after several hours, which may be indicative of the problem originally referenced in this thread. This is a unit that has the I2C hub in place.