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 <feste...@gmail.com>
Sent: Wednesday, November 2, 2022 13:15
To: SCHNEIDER Johannes
Cc: Pali Rohár; Fabio Estevam; Tim Harvey; u-boot@lists.denx.de;
peng....@oss.nxp.com; sba...@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.schnei...@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
