Status of debug UART on am335x SoC

[Simon Glass]

Hi Paul,

On Sat, 15 Oct 2022 at 06:11, Paul Barker <paul.barker at sancloud.com> wrote:
>
> Hi folks,
>
> While looking into SPI boot failures on our am335x based boards I needed
> to enable the debug UART to understand where u-boot was getting stuck.
> I first enabled the following config options:
>
> * CONFIG_DEBUG_UART=y
> * CONFIG_DEBUG_UART_BASE=0x44e09000
> * CONFIG_DEBUG_UART_CLOCK=48000000
> * CONFIG_DEBUG_UART_OMAP=y
> * CONFIG_DEBUG_UART_SHIFT=2
> * CONFIG_DEBUG_UART_ANNOUNCE=y
>
> With these options enabled the debug UART did not function, no output
> was printed at all.
>
> This was fixed by reverting commit 0dba45864b2a ("arm: Init the debug
> UART"), as was discussed in another recent thread [1].
>
> [1]: https://lore.kernel.org/all/CAJs94EYv55QBjvqB94Bwy-wv2_u7tJ+AMP0Ho_XAC8eqjT8BOQ@mail.gmail.com/
>
> Has anyone had chance to look into this further?
>
> It would be good to get this fixed so that the debug UART can be used on
> these boards by simply enabling the correct config options. I'm happy to
> help look into this if anyone has any pointers on where to start.

My guess is that there is SoC init code which needs to be pulled into
the board_debug_uart_init() function.

The tricky thing is that this code needs to be written such that it
does not use any drivers, etc. It needs to enable clocks, etc. as
needed.

The easiest way to debug this is probably to bisect your back back to
crt0.S from the place where the debug UART does work, identifying bits
of init which are critical to the uart.

>
> Thanks,
>
> --
> Paul Barker
> Principal Software Engineer
> SanCloud Ltd
>
> e: paul.barker at sancloud.com
> w: https://sancloud.com/

Regards,
SImon