[U-Boot] [PATCH V4] console: Implement pre-console buffer

[Vadim Bendebury <vbendeb@chromium.org>]

On Tue, Sep 27, 2011 at 4:22 AM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Vadim,
>
> On 27/09/11 08:50, Vadim Bendebury wrote:
>> On Wed, Aug 31, 2011 at 5:58 AM, Graeme Russ <graeme.russ@gmail.com> wrote:
>>> Allow redirection of console output prior to console initialisation to a
>>> temporary buffer.
>>>
>>> To enable this functionality, the board configuration file must define:
>>> ?- CONFIG_PRE_CONSOLE_BUFFER - Enable pre-console buffer
>>> ?- CONFIG_PRE_CON_BUF_ADDR - Base address of pre-console buffer
>>> ?- CONFIG_PRE_CON_BUF_SZ - Size of pre-console buffer (in bytes)
>>>
>>> The pre-console buffer will buffer the last CONFIG_PRE_CON_BUF_SZ bytes
>>> Any earlier characters are silently dropped.
>>>
>>> Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
>
> [snip]
>
>>
>> I know I am late to the party here, but all of a sudden I need to
>> implement something similar, albeit slightly different:
>
> better late than never :)
>
>> - the memory could be allocated by the "cold bootprom" which starts u-boot;
>
> Typically, the pre-console buffer would exist in the CPU cache (or similar
> non-(S)DRAM location)
>
hi Graeme,

Actually, there are many cases when u-boot starts running with memory
fully initialized - ARM platforms is one case and coreboot/u-boot
combination on x86 is another, but in general, yes, this buffer could
be mapped to the internal CPU memory nailed to a fixed address.

>> - all console output needs to be saved, not just until the moment when
>> the console hardware is initialized.
>
> That could be a _huge_ amount of info and highly variable. Remember, the
> available space for a pre-console buffer could be tiny. If this is needed,
> then maybe look at forking stdio instead (one branch to console, one branch
> to you console buffer)
>

Sure, if the room in the preallocated buffer is not enough, only the
most recent data fitting in the space would be kept.

I don't quite understand what you mean by "forking stdio". I was
thinking about introducing a separate driver for this memory stored
console output, but sjg@ explained that while running from ROM u-boot
supports only one console interface, so there is no way to have
console stream sent to more than one driver before relocation.

>> I could work on top of this patch and send another one once this one
>> has been accepted. May I suggest an improvement though:
>>
>> is it really necessary to store the index in the global data
>> structure. This requires editing all these .h files adding another
>> unsighty ?conditionally compiled field. Why not to store the index as
>> the first word in the buffer allocated for this temp storage?
>
> I like this - but instead:
>
> struct pre_con_buff {
> ? ? ? ?int idx;
> ? ? ? ?char *buffer[CONFIG_PRE_CON_BUF_SZ];
> }
>
> struct pre_con_buff *pre_con_buffer;
>
> pre_con_buffer = (struct pre_con_buff *)CONFIG_PRE_CON_BUF_ADDR;
>

yes, this is exactly what I meant,

cheers,
/vb

> Regards,
>
> Graeme
>