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

[Simon Glass]

Hi Wolfgang,

On Sun, Oct 16, 2011 at 12:47 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ0RjEhY7-n4=vFACgzpvSgMZJOjaCbngbdB1J2HaxFK6Q at mail.gmail.com> you wrote:
>>
>> > But that's exactly how it's supposed to work. =A0Depending on hardware
>> > that may or may not be FIFOs available to buffer such asynchronous
>> > input, and I rather see limited, but consistent behaviour, instead of
>> > fancy stuff that works oin one board but not on another.
>>
>> Well this is particular serial driver is in pretty widespread use. We
>
> Widespread, yes.  But there is still a huge number of boards where it
> is not being used.

Yes.

>
>> > If you want to run multi-line command sequences, then load and run a
>> > script.
>>
>> If the setenv commands are configuration commands (such as network
>> config, or setting up a new boot path) then they may not already exist
>> in the machine. It is much easier to paste commands from a text editor
>> / notepad than create a script, put it onto the tftp server, tftp the
>> script and run it.
>
> Well, there is two cases:
>
> - You are doing this just once or twice: then it does not make much
>  sense to create scripts or use tools; but then it is not too much of
>  an issue to copy & paste line by line either.
>
> - You are doing this more frequently.  Then copy & paste is a
>  cumbersome and error prone procedure. You have to be careful about
>  quoting etc., and errors are not easy to detect.  In such a
>  situation it always makes sense to think about more efficient ways:
>
>  1) Use tools.  For example, use something like "expect" or similar
>     to send your inout line by line, always waiting for the next
>     command prompt.
>
>  2) Use a U-Boot script image which you can download and run.
>
>  3) Use a plain text file which you can "env import".
>
>  4) ...

I think this is what said before. In the case of expect, I must put
the board into the right state, disconnect my terminal from the board,
run the expect script and re-connect.

In the case of 2 and 3, they are essentially the same. Both require a
file transfer to the board (perhaps tftp) which involves editing and
putting the file somewhere.

This is not friendly behaviour.

>
>> > In the special case of setting environment variables, consider using
>> > featurs like "env import" instead.
>>
>> s/and run it/and "env import" it/
>
> No.  Running a script image is one solution;  using "env import" is
> another, independent one.

To repeat the bit of my message that you omitted:

> If the setenv commands are configuration commands (such as network
> config, or setting up a new boot path) then they may not already exist
> in the machine. It is much easier to paste commands from a text editor
> / notepad than create a script, put it onto the tftp server, tftp the
> script and run it.

My point was that they both require putting the file somewhere and
using the network to get the file.

>
>> > Multi-line input has never been supported.
>>
>> Hence this patch, I feel. Pasting a number of lines into the terminal
>> is convenient, natural, useful, and when it fails it is unexpected and
>> feels like a bug to many. I would certainly like to fix it.
>
> But your patch does not _solve_ the problem.  It just extends the
> limits a bit - to som degree that seems to be acceptable to you, but
> the next person might paste a few lines more, and it's failing again.

Well I would like to have a message that a serial overflow happened -
we don't have the means to check this at present but perhaps one
day...

With this patch, using commands like setenv that don't emit output, I
can paste at least 50 lines of text.

The problem over buffer overflow is not soluble in the limit. I could
paste the works of Shakespeare into U-Boot but it would run out of
buffer memory. There is always a buffer limit - at present it is about
16 characters which means within a few lines you run of space. This
patch increases that to 256 characters.

I have already granted that the patch should perhaps move up a level,
to encompass serial, but the serial layer is not ready for that yet.

>
> I think it's much better to state clearly that multi-line input is not
> supported than to claim it is, without being able to give a precise
> limit where it will fail, or without being able to detect error
> situations clearly.

I would agree with this if there were an error message or warning that
serial input overflow occurred. At the moment it is just confusing or
buggy.

Regards,
SImon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Little known fact about Middle Earth:   The Hobbits had a very sophi-
> sticated computer network!   It was a Tolkien Ring...
>