On 10/28/24 1:25 AM, Weijie Gao wrote:
Hi Daniel,
On Sat, 2024-10-26 at 20:23 +0100, Daniel Golle wrote:
External email : Please do not click links or open attachments until
you have verified the sender or the content.
Hi!
On Mon, Oct 21, 2024 at 08:56:42AM +0800, Weijie Gao wrote:
It's observed that the bootmenu on a serial console sometimes
incorrectly quitted with superfluous characters filled to command
line input:
*** U-Boot Boot Menu ***
1. Startup system (Default)
2. Upgrade firmware
3. Upgrade ATF BL2
4. Upgrade ATF FIP
5. Load image
0. U-Boot console
Press UP/DOWN to move, ENTER to select, ESC to quit
MT7988> [B
Analysis shows it was caused by the wrong logic of bootmenu_loop:
At first the bootmenu_loop received the first ESC char correctly.
However, during the second call to bootmenu_loop, there's no data
in the UART Rx FIFO. Due to the low baudrate, the second char of
the down array key sequence hasn't be fully received.
But bootmenu_loop just did a mdelay(10), and then treated it as a
single ESC key press event. It didn't even try tstc() again after
the 10ms timeout.
This patch fixes this issue by letting bootmenu_loop check tstc()
twice.
The patch helps to fix the problem when dealing with single key
presses. However, apparently this is not enough to fix the issue in
all situations. I still manage to drop into U-Boot console with an
extra '[A' when simply holding down the arrow-up key for a while.
Holding down the arrow-up key for a while can cause the PC to send
large amounts of data to the UART Rx FIFO. Since filogic UARTs usually
have only 32 bytes FIFO, it's very easy to cause Rx FIFO overflow,
and then you'll still be dropped into U-Boot console due to data loss.
I've already confirmed this during solving this issue and this can only
be solved by increasing the baudrate.
Does CONFIG_SERIAL_RX_BUFFER help with those overflows ?
