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