arm64: csdlock at early boot due to slow serial (?)
Breno Leitao
leitao at debian.org
Thu Jul 3 03:02:39 PDT 2025
On Wed, Jul 02, 2025 at 06:20:36PM +0100, Leo Yan wrote:
> Hi Breno,
>
> On Wed, Jul 02, 2025 at 10:10:21AM -0700, Breno Leitao wrote:
>
> [...]
>
> > Further debugging revealed the following sequence with the pl011 registers:
> >
> > 1) uart_console_write()
> > 2) REG_FR has BUSY | RXFE | TXFF for a while (~1k cpu_relax())
> > 3) RXFE and TXFF are cleaned, and BUSY stay on for another 17k-19k cpu_relax()
> >
> > Michael has reported a hardware issue where the BUSY bit could get
> > stuck (see commit d8a4995bcea1: "tty: pl011: Work around QDF2400 E44 stuck BUSY
> > bit"), which is very similar. TXFE goes down, but BUSY is(?) still stuck for long.
> >
> > If I am having the same hardware issue, I suppose I need to change that logic
> > to exist the cpu_relax() loop by checking when Transmit FIFO Empty (TXFE) is 0
> > instead of BUSY.
> >
> > Anyway, any one familar with this weird behaviour?
>
> To be clear, I am not familiar with pl011 driver.
>
> For the first step, could you confirm the UART port is only used by
> Linux kernel?
>
> In some cases, if normal world and secure world share the same UART
> port, it can cause the UART state machine malfunction and long wait.
I don't know how to check it for sure, but, looking at the serial
console output, I don't see anything else using the UART. The only
output I see on the console at that time is coming from linux kernel.
Would you recommend any additional check?
Thanks for the reply,
--breno
More information about the linux-arm-kernel
mailing list