[PATCH v5 2/2] serial: mxc: have putc use the TXFIFO

[SCHNEIDER Johannes]

Hi Fabio,

>On 25/10/2022 18:37, Tim Harvey wrote:
>
>> Fabio and Pali,
>>
>> Seems reasonable but this does not resolve the problem. Whatever I
>> print in board_init gets cutoff by the print from dm_announce.
>>You are right.
>>
>I managed to reproduce it:
>
>--- a/board/warp7/warp7.c
>+++ b/board/warp7/warp7.c
>@@ -71,6 +71,7 @@ int board_init(void)
>         /* address of boot parameters */
>         gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>
>+       printf("*******************0123456789012345678901234567890123456789\n");
>         return 0;
>  }

sadly that does not reproduce on imx8mm ... a long print works fine with or without the patch :-S

> The RTC line is displayed from drivers/misc/gsc.c and the Core: comes
>from dm_announce. Somehow in between the FIFO does not get drained
>before dm_announce gets called.

"flushing" shouldn't be an issue, since everything goes through the same set of registers which the imx queues into its fifo...
i suspect the rootcause lies someplace else?


regards


regards

________________________________________
From: Fabio Estevam <festevam at gmail.com>
Sent: Wednesday, November 2, 2022 13:15
To: SCHNEIDER Johannes
Cc: Pali Rohár; Fabio Estevam; Tim Harvey; u-boot at lists.denx.de; peng.fan at oss.nxp.com; sbabic at denx.de; trini; GEO-CHHER-bsp-development; Peng Fan
Subject: Re: [PATCH v5 2/2] serial: mxc: have putc use the TXFIFO

This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.


Hi Johannes,

On Wed, Nov 2, 2022 at 2:16 AM SCHNEIDER Johannes
<johannes.schneider at leica-geosystems.com> wrote:

> sadly the previously mentioned printf with a long string (longer than 32bytes) does not trigger the issue on the debug-serial...
> (running on an imx8mm -> uart3 out of 4, and with uboot/v2202.07)
>
> but what puzzles me most is that with my current setup (different tool: old analog oscilloscope replaced by an usb logic-analyzer, and a more recent software versions also on the receiving end where the problem cropped up originally) i'm currently unable to reproduce the original issue i saw - and described in the commit message :-S
> back then the situation was as follows: with the analog scope on uart4 visually comparing waveforms clearly showed different message lengths when comparing u-boot generated traffic (without the patch = short, with the patch = "correct" length) with a reference/working signal generated from within a running linux.
> the receiving end did not respond to the messages from within uboot prior to the patch; but did so with the TXFULL applied and also always when communication was initiated from linux
>
> i still would argue to keep the change, since both the linux kernel and $other bootloaders make use of the TXFULL flag

The problem is that your change is causing a regression as reported by
Tim. It can be easily reproduced.

Please help fix it, otherwise, we will need to revert your change.

Thanks,

Fabio Estevam