Hey Stephan, On Monday, 1 June 2026 at 6:41 PM, Stephan Gerhold <[email protected]> wrote:
> On Mon, Jun 01, 2026 at 06:12:56PM +1000, Sam Day via B4 Relay wrote: > > From: Sam Day <[email protected]> > > > > At least on UARTDM 1.3, I was noticing the early UART debug banner > > getting corrupted. It turns out this is because U-Boot was > > re-initializing the UARTDM block and writing to it before it had > > finished shifting out the FIFO from the previous bootloader. Waiting for > > TX_EMPTY in the status register consistently fixes the issue. > > > > Signed-off-by: Sam Day <[email protected]> > > --- > > drivers/serial/serial_msm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c > > index 10948e2aede..db085d68a0d 100644 > > --- a/drivers/serial/serial_msm.c > > +++ b/drivers/serial/serial_msm.c > > @@ -351,6 +351,8 @@ static inline void _debug_uart_init(void) > > * - HMIBSC: GCC_BLSP1_UART1_APPS_CLK > > */ > > //apq8016_clk_init_uart(0x1800000, <uart_clk_id>); > > + while (!(readl(init_serial_data.base + UARTDM_SR) & UARTDM_SR_TX_EMPTY)) > > + ; > > I think you need to add some timeout here. There is some funky SoC where > the UART is left in some half-disabled state and this bit will never > become unset. Maybe it was MSM8909, I don't remember exactly. I have > similar code in TF-A and there I had to add the timeout to prevent the > device from getting completely stuck during boot sometimes because of > this loop: > > https://github.com/ARM-software/arm-trusted-firmware/blob/da738d5eae93af342fdc4995dd3c05acb4c9d757/plat/qti/bear/msm8916/aarch32/uartdm_console.S#L68-L81 Thanks, that makes sense. v2 will bound this wait loop to 10ms. -Sam > > Thanks, > Stephan >
