From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vadim Bendebury Date: Tue, 27 Sep 2011 07:55:50 -0700 Subject: [U-Boot] [PATCH V4] console: Implement pre-console buffer In-Reply-To: <4E81B1FC.8020607@gmail.com> References: <1314794155-14186-1-git-send-email-graeme.russ@gmail.com> <1314795505-14321-1-git-send-email-graeme.russ@gmail.com> <4E81B1FC.8020607@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Sep 27, 2011 at 4:22 AM, Graeme Russ wrote: > Hi Vadim, > > On 27/09/11 08:50, Vadim Bendebury wrote: >> On Wed, Aug 31, 2011 at 5:58 AM, Graeme Russ 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 > > [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 >