Yep, that's exactly what's happening. tl;dr summary is that HDMI isn't being disabled, although the capemgr (I presume) seems to think it is.
So: I have the HDMI overlays disabled in uEnv.txt: here's the relevant line: optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN And this setup was working working fine under 3.8. Here's my state after boot # cat /sys/devices/bone_capemgr.6/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV1 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-I2C1 As you can see the HDMI virtual capes are not loaded. Now I load UART5: # echo BB-UART5 > /sys/devices/bone_capemgr.6/slots No error: the overlay loads and I get a /dev/ttyO5, but it's quiet, and I see this in the logs: [ 74.569278] bone-capemgr bone_capemgr.6: part_number 'BB-UART5', version 'N/A' [ 74.569372] bone-capemgr bone_capemgr.6: slot #9: generic override [ 74.569402] bone-capemgr bone_capemgr.6: bone: Using override eeprom data at slot 9 [ 74.569432] bone-capemgr bone_capemgr.6: slot #9: 'Override Board Name,00A0,Override Manuf,BB-UART5' [ 74.569589] bone-capemgr bone_capemgr.6: slot #9: Requesting part number/version based 'BB-UART5-00A0.dtbo [ 74.569621] bone-capemgr bone_capemgr.6: slot #9: Requesting firmware 'BB-UART5-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 74.572522] bone-capemgr bone_capemgr.6: slot #9: dtbo 'BB-UART5-00A0.dtbo' loaded; converting to live tree [ 74.572840] bone-capemgr bone_capemgr.6: slot #9: #2 overlays [ 74.584829] pinctrl-single 44e10800.pinmux: pin 44e108c4.0 already requested by hdmi.7; cannot claim for 481aa000.serial [ 74.596454] pinctrl-single 44e10800.pinmux: pin-49 (481aa000.serial) status -22 [ 74.604185] pinctrl-single 44e10800.pinmux: could not request pin 49 (44e108c4.0) from group pinmux_bb_uart5_pins on device pinctrl-single [ 74.617410] omap_uart 481aa000.serial: Error applying setting, reverse things back [ 74.636557] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/serial@481aa000[0]' [ 74.643806] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62, base_baud = 3000000) is a OMAP UART5 [ 74.644534] bone-capemgr bone_capemgr.6: slot #9: Applied #2 overlays. On a hunch I plugged in my HDMI monitor and I can see my console. HDMI is enabled. Although I've got a large wobbly green smudge, a result of my GPS which is hardwired to the same pins! I suppose if I could just interpret that I could figure out the position that way... I'm not sure where to go from here. HDMI doesn't seem to be properly disabled: the OS thinks it is, and the capemanager lets me load the cape, but my screen still works (including fairly early during the boot process) and clearly the pinmux won't free the pins for the UART. I've booted with and without the cape, same result. * If anyone else has disabled HDMI on kernel 3.12, try plugging in a monitor anyway. See anything? * If anyone has any suggestions, please let me know, I'm happy to test them. On 20 November 2013 22:42, William Hermans <[email protected]> wrote: > Bert, I have not looked but is there a pin conflict ? Perhaps with a emmc > pin , or possibly hdmi ? If so and in the case of emmc I have been told > that once booted, you *can* reclaim a few pins back from the eMMC. Then in > the case of hdmi, if not used you can just disable it via uEnv.txt. > > > On Wed, Nov 20, 2013 at 12:36 PM, Bert Lindner <[email protected]>wrote: > >> On Wednesday, November 20, 2013 1:56:55 PM UTC+1, Mike Bremford wrote: >>> >>> Finally found the required changes to get UART1, 2, 4 and 5 loaded and >>> numbered correctly under 3.12. >>> >>> The source for the "capes" I was looking for (BB-UARTn) were created by >>> this patch: https://github.com/beagleboard/kernel/blob/3.8/ >>> patches/not-capebus/0176-capes-Add-virtual-capes- >>> serving-as-examples.patch, and it looks like the RS232 cape would need >>> the same change. The file isn't in the 3.12 branch and I don't speak git so >>> I've attached a patch for this patch (sorry) which fixes the UART and RS232 >>> overlays. >>> >>> If anyone just needs working DTS and DTBO files for BB-UART1, BB-UART2, >>> BB-UART4 and BB-UART5 for kernel 3.12, I'm attaching them here as well in >>> bb-uart-dts-312.tar.gz >>> >>> >> Just to confirm that all UARTs appear as expected on my BBB Rev. A5C >> running Robert's Ubuntu 13.04 image with kernel 3.12.0-bone8. >> >> I've tried the RX signals (with a GPS board), they all work apart from, >> for some reason, UART5/RX (P9/38). Not sure what the issue is there. >> >> Thanks again, best, >> >> -Bert >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
