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

Graeme Russ graeme.russ at gmail.com
Wed Oct 26 05:41:39 CEST 2011


Hi Simon,

On Wed, Oct 26, 2011 at 10:48 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Graeme,
>
> On Tue, Oct 25, 2011 at 4:37 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Simon,
>>
>> On Wed, Oct 26, 2011 at 10:17 AM, Simon Glass <sjg at chromium.org> wrote:
>>
>> [big snip]
>>
>>> Did I mention a can of worms? After 65 messages on this topic Scott's
>>> patch seems pretty appealing right now! We can even move it up a level
>>> in the s/w stack if that helps.
>>
>> But I agree with Wolfgang that Scott's proposal only hides the real
>> problem even deeper and will make a real solution more difficult
>> next time around
>
> I feel that the 'real' solution is flow control or buffering and probably both.
>
>>
>>> But to continue this a little, and donning my asbestos suit, should
>>> U-Boot have a CONFIG to enable an event loop called in delay
>>> functions, network functions, read/write operations, etc.? It would
>>> permit us to solve this problem properly I think, if we think it is
>>> worth solving. Not saying it is a good idea...
>>
>> That is what the watchdog code does - It is a horrible hack, and every now
>> and again, another patch comes through which adds another call to the
>> watchdog trigger in some obscure loop in some obscure code location. Or
>> someone submits new code for a board that does not have a watchdog that
>> somebody else then uses on a board that does have one and the watchdog
>> suddenly triggers resetting the board. It's messy and ugly.
>>
>> My biggest point about the 'dropped character' issue is that the fix is
>> simple provided the 'tasks' that use the serial console behave and inform
>> the serial console driver that they have finished receiving characters -
>> not a big ask in my opinion. Way smaller that spattering 'Check the
>> serial port' all over the code
>
> I kind-of agree so long as it is more of an event loop and less of
> something specific to serial (of course serial might be the only
> customer but then we could display a spinning thing on the LCD...)

I don't think we need to get too fancy - U-Boot is not an OS :)

> Funnily enough that problem (one bit of code wanting to tell serial
> something) exists on Seaboard, where the SPI driver has to tell the
> UART to flush or invalidate since they cannot co-exist. And that is
> why I was so interested in this patch.

Well, I have the feeling than an console API might be in order. The way
U-Boot is structured at the moment, serial I/O is kind of taken for
granted to 'just exist' and nobody needs to really be self-aware that
they use it - The same cannot be said of users of USB and Network -
Net is a good example - all 'users' of net call NetLoop() which does
an eth_init()...do stuff...eth_halt()

So maybe a serial API which 'users' must 'wake up' and 'sleep'...

 - console_configure() - Set parameters (port, baud rate etc)
 - console_wake() - Prepare the console (could be serial, USB, netconsole)
 - console_flush() - Throw away any buffered characters
 - console_getc(), console_putc(), console_tstc() - Self explainatory
 - console_sleep() - Shut the console down (send XOFF, turn of USB etc)

This would resolve the issue were devices are multiplexed with the serial
UART like your SPI example. The command line interpreter calls
console_sleep() to release the serial UART resource before the command
which uses the multiplexed device wakes that device, does it's thing and
shuts the device down before returning to the command line interpreter
which wakes up the serial UART...

Regards,

Graeme



Regards,

Graeme


More information about the U-Boot mailing list