Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems #2856

willdean · 2019-02-13T15:45:06Z

Describe the bug

We're running 4.19 on a CM3+, with UART0 mapped to GPIO36/37.

The relevant config.txt line is

dtoverlay=uart0,txd0_pin=36,rxd0_pin=37,pin_func=6

We're seeing that the UART doesn't get initialised, with the following errors in dmesg

[    0.737582] pinctrl-bcm2835 3f200000.gpio: pin gpio14 already requested by leds; cannot claim for 3f201000.serial
[    0.737883] pinctrl-bcm2835 3f200000.gpio: pin-14 (3f201000.serial) status -22
[    0.738082] pinctrl-bcm2835 3f200000.gpio: could not request pin 14 (gpio14) from group gpio14  on device pinctrl-bcm2835
[    0.738373] uart-pl011 3f201000.serial: Error applying setting, reverse things back
[    0.738598] uart-pl011: probe of 3f201000.serial failed with error -22

The serial port should not be trying to talk to GPIO14 - that's running a DPI LCD panel, and we are wondering if it is trying to talk to GPIO14 because of the following patch:

68accec#diff-2991a7f22e210883f9428277cb77ede7

I don't fully understand how this change works, or what's going on, but we'd like UART0 not to touch GPIO14/15 at all. Or, at least, not fail if it finds it can't touch GPIO14/15.

We're not clear about the origin of the "pin gpio14 already requested by leds" message - there aren't any LEDs we're aware of, though the GPIO14 is in use elsewhere.

We feel as though this didn't happen with the latest 4.14, though we're in a very complex mix of moving parts at the moment, and we could be wrong about this.

I've attached a raspinfo output.

The text was updated successfully, but these errors were encountered:

pelwell · 2019-02-14T11:04:09Z

The uart0 overlay is using pinctrl to return the original UART pins 14 & 15, as initialised by the firmware, back to input. This has the side effect of leaving them claimed. The dpi overlays also use pinctrl, via the "gpio-leds" driver, to enable the DPI function on the same pins, also claiming them. One of them has to lose, and in this case it's the DPI overlay.

Without changing the firmware, the easiest way forward for you is to copy the old version of the overlay and give it a unique name that won't be used by anyone else, to prevent it being overwritten by future updates.

willdean · 2019-02-14T12:16:30Z

Thanks @pelwell, in our case it's actually the serial port losing rather than the DPI but I get the point and we'll try the suggested fix, thanks.

It seems like this change (I do appreciate what the motivation for it was) will bite anyone whose boot process allocated GPIO14/15 to something else before loading the uart overlay. Is it somehow possible for the failure to allocate these pins (solely for the purpose of setting them as input) to be 'soft' - i.e. if they can't be allocated then things will just plough-on anyway?

Or could there be some optional overlay parameter which enabled/disabled this behaviour, perhaps?

pelwell · 2019-02-14T13:35:44Z

I like the overlay parameter idea - it's easy enough to do. Give me a moment...

pelwell · 2019-02-14T15:25:07Z

On second thoughts, this a problem created by the firmware (and its dt-blob), so it should be solved in the firmware. The fix is going to take a bit more thought, but the intention is to revert the offending commit and let the firmware undo any contention.

willdean · 2019-02-14T16:23:06Z

@pelwell - So the plan is to make the firmware release/set-to-input these pins, at which point the uart overlay won't need to touch them at all if it's actually mapped to different pins?

That does makes sense if so - it does seem to avoid fix upon fix upon fix.

pelwell · 2019-02-14T16:25:49Z

Yes, that's the plan. In an ideal world this would all be left to Device Tree, but the firmware configures (and can use) the UART, and other OS's may depend on the pins being configured before they are started.

JamesH65 · 2019-09-19T13:16:18Z

@pelwell Did this plan ever come to fruition?

pelwell · 2019-09-19T13:19:05Z

No, but recent changes to the order of file loading by the firmware should have made it a more tractable problem.

pelwell · 2019-09-28T10:46:50Z

Another victim: https://www.raspberrypi.org/forums/viewtopic.php?t=252911
This issue is now top of the list.

arthurlavalabs · 2019-09-28T16:11:32Z

Please note my report as well: https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252389

The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: raspberrypi#2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: #2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

pelwell · 2020-01-30T09:29:16Z

The underlying cause of this issue has been fixed in the firmware since October. The required overlay change has been in the 5.4 tree since then, but wasn't merged to 4.19 to give users time to update their firmwares. Sufficient time as now passed, and the modified overlay has been merged to 4.19.

The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: #2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

See: raspberrypi/linux#3434 kernel: adds LED OFF feature to HiFiBerry DAC+ADC sound card See: raspberrypi/linux#3435 kernel: adds LED OFF feature to HiFiBerry DAC+/DAC+PRO sound cards See: raspberrypi/linux#3436 kernel: fix master mode settings of HiFiBerry DAC+ADC PRO card See: raspberrypi/linux#3424 kernel: pisound: Added reading Pisound board hardware revision and exposing it See: raspberrypi/linux#3425 kernel: Fix i2c-pwm-pca9685a overlay See: raspberrypi/linux#3431 kernel: tty: amba-pl011: Add un/throttle support kernel: tty: amba-pl011: Avoid rare write-when-full error See: #1150 kernel: ARM: dts: Declare RPi 4B SD card power regulator kernel: usb: xhci: Raspberry Pi FW loader for VIA VL805 kernel: overlays: Correct the eth_led* colour assignments See: #1311 kernel: overlays: Remove hack from uart0 overlay See: raspberrypi/linux#2856 kernel: ARM: dts: Add sd_poll_once dtparam to bcm283x/2711 See: raspberrypi/linux#3286 firmware: isp/tuner: Resetting to a lamp mode cancels manual_gains_used_ firmware: board_info: Fix uninitialised phy_addr handling in network boot firmware: IL video_decode: Default to H264 as MPEG4 isn't supported firmware: IL egl_render: Fail the create on Pi4 firmware: arm_dispmanx: Column pitch for YUV10COL is in lines not bytes firmware: platform: 2711: Also add chicken bits to dvfs voltage firmware: MMAL / video_render: Allow column stride to be set on column formats firmware: vc_image/video_decode: Move +16 lines for di_adv from vc_image to decoder

See: raspberrypi/linux#3434 kernel: adds LED OFF feature to HiFiBerry DAC+ADC sound card See: raspberrypi/linux#3435 kernel: adds LED OFF feature to HiFiBerry DAC+/DAC+PRO sound cards See: raspberrypi/linux#3436 kernel: fix master mode settings of HiFiBerry DAC+ADC PRO card See: raspberrypi/linux#3424 kernel: pisound: Added reading Pisound board hardware revision and exposing it See: raspberrypi/linux#3425 kernel: Fix i2c-pwm-pca9685a overlay See: raspberrypi/linux#3431 kernel: tty: amba-pl011: Add un/throttle support kernel: tty: amba-pl011: Avoid rare write-when-full error See: raspberrypi/firmware#1150 kernel: ARM: dts: Declare RPi 4B SD card power regulator kernel: usb: xhci: Raspberry Pi FW loader for VIA VL805 kernel: overlays: Correct the eth_led* colour assignments See: raspberrypi/firmware#1311 kernel: overlays: Remove hack from uart0 overlay See: raspberrypi/linux#2856 kernel: ARM: dts: Add sd_poll_once dtparam to bcm283x/2711 See: raspberrypi/linux#3286 firmware: isp/tuner: Resetting to a lamp mode cancels manual_gains_used_ firmware: board_info: Fix uninitialised phy_addr handling in network boot firmware: IL video_decode: Default to H264 as MPEG4 isn't supported firmware: IL egl_render: Fail the create on Pi4 firmware: arm_dispmanx: Column pitch for YUV10COL is in lines not bytes firmware: platform: 2711: Also add chicken bits to dvfs voltage firmware: MMAL / video_render: Allow column stride to be set on column formats firmware: vc_image/video_decode: Move +16 lines for di_adv from vc_image to decoder

popcornmix · 2020-01-30T16:48:34Z

rpi-update contains the potential fix. Can you test it?

The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: #2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Source: kernel.org MR: 103889 Type: Enhancement Disposition: Merged from https://github.com/raspberrypi/linux.git rpi-5.4.y ChangeID: d56c8c2ba65d3ec3dbb94e686e3788e35b782974 Description: The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: raspberrypi/linux#2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>

The uart0 overlay contained a hack to return GPIOs 14 and 15 to inputs when the UART0 function was moved to alternative pins. This has the unwanted side effect of claiming GPIOs 14 & 15, preventing them being used for something else. See: #2856 https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=252911 Signed-off-by: Stefan Enge <stefan.enge@escatec.com> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

kalvdans · 2021-10-08T20:14:14Z

Close?

willdean changed the title ~~Recent changes to GPIO14/15 may have stopped Uart initialisting on DPI systems~~ Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems Feb 13, 2019

JamesH65 added the Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team label Sep 19, 2019

pelwell self-assigned this Sep 19, 2019

pelwell added Close within 30 days Issue will be closed within 30 days unless requested to stay open and removed Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team labels Jan 30, 2020

pelwell closed this as completed Oct 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems #2856

Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems #2856

willdean commented Feb 13, 2019

pelwell commented Feb 14, 2019

willdean commented Feb 14, 2019

pelwell commented Feb 14, 2019

pelwell commented Feb 14, 2019

willdean commented Feb 14, 2019

pelwell commented Feb 14, 2019

JamesH65 commented Sep 19, 2019

pelwell commented Sep 19, 2019 •

edited

Loading

pelwell commented Sep 28, 2019

arthurlavalabs commented Sep 28, 2019

pelwell commented Jan 30, 2020

popcornmix commented Jan 30, 2020

kalvdans commented Oct 8, 2021

Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems #2856

Recent changes to GPIO14/15 may have stopped Uart initialising on DPI systems #2856

Comments

willdean commented Feb 13, 2019

pelwell commented Feb 14, 2019

willdean commented Feb 14, 2019

pelwell commented Feb 14, 2019

pelwell commented Feb 14, 2019

willdean commented Feb 14, 2019

pelwell commented Feb 14, 2019

JamesH65 commented Sep 19, 2019

pelwell commented Sep 19, 2019 • edited Loading

pelwell commented Sep 28, 2019

arthurlavalabs commented Sep 28, 2019

pelwell commented Jan 30, 2020

popcornmix commented Jan 30, 2020

kalvdans commented Oct 8, 2021

pelwell commented Sep 19, 2019 •

edited

Loading