Dear Simon,
In message CAPnjgZ3p20664FOc9vPaV=z3dEdv7T=mmLpwbSy8NjiFUP2A8w@mail.gmail.com you wrote:
- This buffering of data in this patch is intended to solve a specific problem that could be avoided by more clever test scripts. Instead of just dumping an endless stream of characters to the serial console independent of what U-Boot is doing, one should always wit for the next CLI prompt before sending the next command. Tools like "expect" can do this easily.
Agreed it could be done that way, but it is so much easier if U-Boot can behave in a simple way with input. We may end up with more complicated test scripts although I would prefer that we focus on unit tests a bit more.
As long as we don't support interrupts on all architectures and convert at least the UART drivers to use an interrupt driven mode we will always face the situation that U-Boot will bi strictly single- threaded and just does not read any input while doing something else, like running a command.
So all test scripts should consider this behaviour of the input interface. If they send more than one line of text to input, they should do it line by line, and always wait for the CLI prompt first.
Yes, this is inconvenient.
Fair enough, I don't disagree with this at all. The use case for buffering is when you have the LCD running and it is quite slow to print characters. You then can't type quickly at the keyboard - U-Boot just gets behind. It happens on snow and seaboard when the caches are off.
Heh. So the obvious solution is to turn the caches on :-)
No - I do understand what you want, and why, and I agree that it would be nice to have.
Best regards,
Wolfgang Denk