BOOT_UART default 1 breaks hats using gpio 14 and 15

[digitalLumberjack]

Describe the bug

Hello :)

With the commit d57c084

The bootloader enable by default BOOT_UART=1 and break support for hats using gpio 14 and 15

Steps to reproduce the behaviour

Update bootloader, reboot with a hat using gpio 14 and 15, see the error.

When setting BOOT_UART=0, it works again

EDIT seems like it does not work again with BOOT_UART=0

Device (s)

Raspberry Pi 5

Bootloader configuration.

[all]
BOOT_UART=1
POWER_OFF_ON_HALT=0
BOOT_ORDER=0xf41

System

[    6.226339] pinctrl-rp1 1f000d0000.gpio: pin gpio14 already requested by 1f00030000.serial; cannot claim for 1f00148000.dpi

Bootloader logs

No response

USB boot

No response

NVMe boot

No response

Network (TFTP boot)

No response

[pelwell]

We are aware, and a fix is in progress. In the meantime, enable_uart=0 in config.txt should work around the problem.

[lurch]

With the commit d57c084

The bootloader enable by default BOOT_UART=1 and break support for hats using gpio 14 and 15

FYI I suspect it was actually fe7bfc7 that changed the behaviour here. (This is just for information; I'm sure that Phil's fix will cure this issue)

[digitalLumberjack]

Thank you, sorry if the feedback was a little bit to early.

[lurch]

No need to apologise, there's no way for you to know that we were already aware of the issue! Thank you for your report.
We spotted this issue ourselves only a couple of days ago 🙂

[nbuchwitz]

This also affects CM5 (luckily only the RS485 RTS gpio in our new product...). I've tested the firmware in #644 and can confirm that this will fix the issue. Thanks for the prompt reaction @pelwell / @timg236.

Any idea when this will be available as package release?

[timg236]

I think the apt update will be wk2 now

[timg236]

@nbuchwitz We managed to get the update out today - last one of the year I hope :)

[nbuchwitz]

Thanks. I guess this can be closed then?