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

[Vadim Bendebury <vbendeb@chromium.org>]

On Thu, Sep 29, 2011 at 4:15 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Vadim,
>
> On Wed, Sep 28, 2011 at 12:55 AM, Vadim Bendebury <vbendeb@chromium.org> wrote:
>> 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:
>
> [snip]
>
>>> 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.
>
> And we have to satisfy the 'absolute majority', not the 'many' or the
> 'simply majority'. And I'm not sure it's always true that ARM platforms
> have fully initialised SDRAM when U-Boot starts
>
>>>> - 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
>
> Search for CONFIG_CONSOLE_MUX - There appears to be support for sending
> stdout to multiple output devices:
>
> static void console_putc(int file, const char c)
> {
> ? ? ? ?int i;
> ? ? ? ?struct stdio_dev *dev;
>
> ? ? ? ?for (i = 0; i < cd_count[file]; i++) {
> ? ? ? ? ? ? ? ?dev = console_devices[file][i];
> ? ? ? ? ? ? ? ?if (dev->putc != NULL)
> ? ? ? ? ? ? ? ?dev->putc(c);
> ? ? ? ?}
> }
>
>
> I don't know have to register additional devices though
>

hi Graeme,

sure, I understand how the console mux works, i was not sure you were
referring to it.


>> 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.
>
> Yes, while running from ROM your options are very limited, but if you have
> a console buffer big enough to get you into RAM you can do lot more
>
>>>> 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,
>>
>
> Thinking more about this, I think I prefer the current patch for two
> reasons:
>
> ?1) gd is guaranteed to be cleared - The memory holding the buffer is not
> ? ?so you would need to initialise it somehow - That could mean splitting
> ? ?the init for each arch

doesn't each console type have an init routine? this would be a place
to initialize the header.

> ?2) pre_con_buffer is larger than CONFIG_PRE_CON_BUF_SZ. This will need to
> ? ?be taken into consideration if the buffer is being crammed into a very
> ? ?tightly crafted memory map - Forgetting to take this into account is
> ? ?going to cause lots of pain. Now you could do:
>
> ? ? ? ?struct pre_con_buff {
> ? ? ? ? ? ? ? ?u16 idx;
> ? ? ? ? ? ? ? ?char *buffer[CONFIG_PRE_CON_BUF_SZ - 2];
> ? ? ? ?}
>

I actually have just implemented this for coreboot.  It has its own
idiosyncrasies of course, the console buffer needs to be kept in three
different places and the contents copied three times on the way up.

I used this structure for the log buffer:

struct pre_con_buff {
? ? ? ? ?u16 size;
         u16 idx;
         char buffer[0]
};

Then, the initialization code  would just get the memory area address
and size, overlay this structure on top of it and set the size field
to

<area size> - sizeof(struct pre_con_buff)

yes, this results in a non power of two buffer size, but IMO the
convenience of keeping everything in one place and  (and not changing
multiple .h files) is worth the lost performance of not being able to
utilize power of two arithmetic optimization (which I think is
negligible in any case).

cheers,
/vb


> ? ?but the buffer size should really be a power two (so the compiler
> ? ?optimises the divides into shifts) - So now we have to define
> ? ?CONFIG_PRE_CON_BUF_SZ as say 258. It's starting to get messy
>
>
> Regards,
>
> Graeme
>