Slot conflict resolution without compiling custom kernel?

[kfatehi]

Hello

First off thank you. Secondly, I have an issue that has so far led me to having to consider compiling my own kernel, which I'd like to avoid. I am thinking there may be an easier solution that is just not well-documented yet.

I have a LCD cape that is causing a conflict in that it is disabling my UART2 in order to provide a hardware button [Enter key]. It is recognized as the BB-BONE-LCD4-01.

Between the LCD cape and the Beaglebone, I have a custom PCB (I call it a cape, but it does not provide an EEPROM with any identification information). This PCB utilizes UART2 via a MAX3232 chip. This was working perfectly fine before stacking the LCD cape.

I thought that I was already overriding the conflict by editing /boot/uboot/uEnv.txt to have the line cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2 but this is not the case. The LCD cape overrides my settings and disables UART2 for the Enter button.

Is there a way to configure the beaglebone to prioritize my decision to enable the UART2 over the Enter key?

Some relevant lines of dmesg:

[    0.710548] bone-capemgr bone_capemgr.9: loader: before slot-8 BB-UART2:00A0 (prio 0)
[    0.710566] bone-capemgr bone_capemgr.9: loader: check slot-8 BB-UART2:00A0 (prio 0)
[    0.710581] bone-capemgr bone_capemgr.9: loader: after slot-8 BB-UART2:00A0 (prio 0)
[    0.710596] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-UART2-00A0.dtbo
[    0.710612] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'BB-UART2-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[    0.710635] bone-capemgr bone_capemgr.9: slot #8: dtbo 'BB-UART2-00A0.dtbo' loaded; converting to live tree
[    0.710792] bone-capemgr bone_capemgr.9: slot #8: BB-UART2 conflict P9.21 (#3:BB-BONE-LCD4-01)
[    0.719838] bone-capemgr bone_capemgr.9: slot #8: Failed verification
[    0.726586] bone-capemgr bone_capemgr.9: loader: failed to load slot-8 BB-UART2:00A0 (prio 0)

Thank you

[RobertCNelson]

Since the dtbo that's causing you issues is already built-into the kernel, you'll have to rebuild..

Just remove the pins attached to the enter key in the dts and you'll be able to use the uart as is..

btw, if you also switch to v3.14.x you can use my dtb-rebuilder, then it's a simple dtb rebuild and not a full kernel build..

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-keymap1.dtsi#L73

Regards,

[kfatehi]

Hi Robert

I tried a 3.14 kernel. My BBB would boot, but the screen would not come on. I then backtracked and tried 3.8. I tried the various guides. Ran into a lot of obstacles and realized I was completely out of my element. Instead I've taken a different approach to customizing the beaglebone.

I've documented it here https://github.com/fatehitech/beaglebench -- maybe others will find it useful too.

Thank you again for all your hard work on this stuff. I almost felt like I knew a thing or two about kernel development while following your detailed wiki notes! I would have taken more notes and spent more time on this road but luckily there were easier ways (like disabling getty to get control of UART0 and using that as my second serial port instead of trying to do manual pin conflict resolution).