Hi Jonas,

On 4/22/24 19:41, Jonas Karlman wrote:
Hi Quentin,

On 2024-04-22 18:41, Quentin Schulz wrote:
From: Quentin Schulz <quentin.sch...@theobroma-systems.com>

UART2 controller is the controller in the reference design for debug
console. The default mux is M0 in that reference design. Until now, all
boards seemed to be using UART2M0 but RK3588 Tiger for example will be
using UART2M2 instead.

Therefore, let's add support for UART2M1 and M2 as possible muxes for
the UART2 controller used as debug console. UART2M1 support was not
tested.

The default value is M0 to match the one used currently by all devices
and the reference design.

Is this really necessary?

Use of board_debug_uart_init() should typically only be needed in TPL on
Rockchip platform, and with ROCKCHIP_TPL being used it should be enough
to use rkbin/ddrbin_tool to change uart config and just ensure correct
pinctrl is used for uart node, and that the uart node is included in SPL
for correct serial console use.


ddrbin_tool is a blob that Rockchip refuses to provide sources of. Running a blob on the target is one thing, requiring our users to run a blob on their build machine is another thing (though I document it in the rST).

However... I don't think we have another way around because I just remembered that if you have two muxes selected for the same UART controller, RX won't work. So while we would have UART output for U-Boot if Rockchip's TPL is one mux (e.g. m0, the default) and upstream U-Boot another one, we wouldn't be able to interact with it.

It'll be necessary the day we have an open-source DRAM init though (I had to do this for PX30 for example).

The issue is that since ddrbin_tool is a blob, it's not possible to use it in Yocto for automatically generating the appropriate ddr bin blob based on uart controller, mux and baudrate. So that will be my cross to bear.

May I suggest you try adding following to defconfig and drop this patch?

   # CONFIG_DEBUG_UART_BOARD_INIT is not set

I would expect that should result in same/working behavior without
having to add any new code.


It does work, thanks for the suggestion, will send a v2.

Cheers,
Quentin

Reply via email to