Deactivate I2C2 Cape Identification

[swizz]

Hello,

I have a weird question/problem.
My Beaglebone Black (IoT image 2020 (no graphical desktop), Kernel 4.19.94) runs a qt Application after bootup, which also uses CAN. As my Touch-Display uses CAN1, I have to use CAN0. I want to boot as fast as possible and already have minimized the boot time to ~20 sec. I have loaded the Display Overlay and the CAN0 Overlay in uEnv.txt, so that I don’t need the i2c cape identification.
Now to the weird problem: When the CAN-Tranceiver is connected to the pins (p9.19/p9.20) and supplied with power, the boot time increases over 10 seconds. I supposed that the i2c cape identification process sees a level on the pins and waits for a communication until a timeout occurs and the boot continues.
I have even recompiled the Device tree Overlay and configured can0 as default pin for p9.19 and p9.20, in hope the cape identification stops.
But the issue still occurs.
I’d appreciate it, If someone could give me a suggestion or a hint.

Best Regards.

[RobertCNelson]

@swizz

Now to the weird problem: When the CAN-Tranceiver is connected to the pins (p9.19/p9.20) and supplied with power, the boot time increases over 10 seconds. I supposed that the i2c cape identification process sees a level on the pins and waits for a communication until a timeout occurs and the boot continues.
I have even recompiled the Device tree Overlay and configured can0 as default pin for p9.19 and p9.20, in hope the cape identification stops.
But the issue still occurs.
I’d appreciate it, If someone could give me a suggestion or a hint.

Humm… so we need to figure out how to bypass this in special cases like yours:

beagleboard/u-boot/blob/v2019.04-bbb.io-am335x/board/ti/am335x/board.c#L252-L262

Regards,