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

[Simon Glass]

On Sat, Oct 15, 2011 at 9:50 AM, Simon Glass <sjg at chromium.org> wrote:
> 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

Another thought...the problem is that every character we receive we
echo, so we can of course never get ahead of the workload.  But we can
get behind, since while we are doing something other than receiving
serial characters (e.g. processing a command, outputing a prompt,
updating the LCD) we are not transmitting. Then when we next go to
receive, we find (say) 10 characters built up, and start echoing them
all. We are now 10 characters behind the receive and will stay that
way until there is a let-up. Even worse if one of the commands outputs
something, since then we might be 20 or 30 characters behind, and
start dropping things. Even if no commands output anything, delays and
the U-Boot prompt will create a problem.

(As an aside, I note the call to the USB code to deal with
transmission/reception so clearly there is some interrupt handling
going on...)

So another approach would be to buffer all output at the console layer
and send it out in the fullness of time using a function similar to
tstc() that tests whether or not there is space in the output fifo.

This seems a more invasive but more general fix. I'm not that keen on
it since it changes something that people might rely on - that
printf() waits if the serial fifo is full. It might mean that prior to
running bootm U-Boot would need to wait for the buffer to flush. Ick.

But I am happy to look at this if you think it isn't even worse.

Regards,
Simon

>
>>
>> Amicalement,
>> --
>> Albert.
>>
>