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

[Graeme Russ]

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]

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

> 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
 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];
	}

    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