Hi Paul,
On Sat, 15 Oct 2022 at 06:11, Paul Barker paul.barker@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].
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@sancloud.com w: https://sancloud.com/
Regards, SImon