[U-Boot] [PATCH v2] NS16550: buffer reads

[Simon Glass]

Hi Albert,

On Sat, Oct 15, 2011 at 9:21 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Le 15/10/2011 18:12, Simon Glass a écrit :
>>
>> Hi Wolfgang,
>>
>> On Sat, Oct 15, 2011 at 9:02 AM, Wolfgang Denk<wd at denx.de>  wrote:
>>>
>>> Dear Simon Glass,
>>>
>>> In
>>> message<CAPnjgZ34FFotBBiqb=Y5xsuyRiavOWud5G2sy9GModsG4LB6=w at mail.gmail.com>
>>>  you wrote:
>>>>
>>>>> A general question: is the issue with input as such, or with echoing
>>>>> this
>>>>> input?
>>>>
>>>> The problem is in echoing the input, since this requires the uart to
>>>> wait once its transmit FIFO is full. While it is waiting (and not
>>>> checking the receive side), it misses characters coming from the other
>>>> end. Basically we need to constantly check the receiving side while we
>>>> are transmitting.
>>>
>>> No, we do not.
>>>
>>> U-Boot is strictly single tasking. This is one of the fundamental
>>> design principles. We do not receive network packets while sending
>>> ourself, or when doing other things. We do not receive characters on
>>> the serial line while sending characters, or when doing other things.
>>>
>>> This is known behaviour, and you should just adapt to it. I don't know
>>> what exactly is your situation when you run into such problems - the
>>> recommended approach for example when remote-controlling U-Boot is to
>>> wait for the next input prompt before sending the next line of
>>> characters - and stop after the newline, until you receive the next
>>> prompt.
>>
>> I certainly don't want to break a fundamental design principle.
>> .
>> The situation this occurs is when you paste characters into a serial
>> terminal connected to U-Boot. This is a pretty common requirement. Yes
>> you can manually select each line and paste it but that is a pain.
>> With this patch it is possible to paste a series of 'setenv' commands,
>> for example.
>>
>> This caused an awful lot of confusion here because characters would be
>> silently dropped within the command line (normally about 16 chars from
>> the end). Then the system would not boot. It is really not a friendly
>> experience.
>>
>> Regards,
>> Simon
>
> How about using the time-honored flow-control mechanism? If the serial port
> supports hardware CTS and RTS signals, you can use them to sync with the
> sender. If not, you can send XOFF and XON to respectively ask the sender to
> pause and resume sending. Of course, the sender must support hardware or
> software flow control.

It is common to have just a 2-wire UART for the console. Perhaps this
is unfortunate.

Are you suggesting that U-Boot should send XOFF sometimes, or does it
support this already? (I haven't seen it). When would U-Boot send
XOFF? Perhaps it could send XOFF at the end of each line that it
receives. Then XON when it starts reading the next line or maybe when
it runs out of characters and wants more.

Most terminal problems will support software flow control. But are you
sure this is better?

Regards,
Simon

>
> Amicalement,
> --
> Albert.
>