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

[Graeme Russ]

Hi Vladim

On Fri, Sep 30, 2011 at 9:39 AM, Vadim Bendebury <vbendeb at chromium.org> wrote:
> On Thu, Sep 29, 2011 at 4:15 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Vadim,
>>
>> On Wed, Sep 28, 2011 at 12:55 AM, Vadim Bendebury <vbendeb at chromium.org> wrote:
>>> On Tue, Sep 27, 2011 at 4:22 AM, Graeme Russ <graeme.russ at 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 at gmail.com> wrote:
>>

[snip]

>>
>>  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.

The point is that with pre-console buffer, we have a storage location for
console output even before any console init routine is run - console is
available as soon as gd is cleared (which is _very_ early indeed)

>>  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.

Ouch!

> 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)

For U-Boot, that sounds like a lot of stuffing around to save two bytes
in gd

> 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).

In an embedded bootloader, every clock counts :) - You desktop junkies are
too used to long boot times ;)

>>    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

And messier (at least in the context of U-Boot - YMMV)

Regards,

Graeme