[U-Boot] [PATCH 2/2] sunxi: Enable pre-console buffer

[Siarhei Siamashka]

On Thu, 08 Jan 2015 08:49:54 +0000
Ian Campbell <ijc at hellion.org.uk> wrote:

> On Thu, 2015-01-08 at 09:02 +0200, Siarhei Siamashka wrote:
> > This allows to always have a complete log on the VGA/HDMI/LCD console.
> > 
> > Signed-off-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>
> > ---
> >  include/configs/sunxi-common.h | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> > index b4324ee..5ddcc42 100644
> > --- a/include/configs/sunxi-common.h
> > +++ b/include/configs/sunxi-common.h
> > @@ -272,10 +272,15 @@
> >  #ifndef CONFIG_SPL_BUILD
> >  #include <config_distro_defaults.h>
> >  
> > +/* Enable pre-console buffer to get complete log on the VGA console */
> > +#define CONFIG_PRE_CONSOLE_BUFFER
> > +#define CONFIG_PRE_CON_BUF_SZ		(1024 * 1024)
> > +#define CONFIG_PRE_CON_BUF_ADDR		(0x43000000 - CONFIG_PRE_CON_BUF_SZ)
> > +
> >  /*
> >   * 240M RAM (256M minimum minus space for the framebuffer),
> > - * 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
> > - * 1M script, 1M pxe and the ramdisk at the end.
> > + * 32M uncompressed kernel, 15M compressed kernel, 1M pre-console
> > + * buffer, 1M fdt, 1M script, 1M pxe and the ramdisk at the end.
> 
> Am I correct in thinking that the pre-console buffer is long gone
> (replaced by the actual console) by the time any of these mem layout
> choices come into play (i.e. long before anything might load a kernel,
> initrd or fdt)?

Yes, my understanding is that it should be already gone, but not too
long ago. Logging in the patched pre-console buffer ends at the time
when the following messages get displayed:
   In:    serial
   Out:   vga
   Err:   vga

Now that you mentioned it, the patch is indeed extending the life time
of the pre-console buffer, and this might be an unwanted side effect.
Maybe Simon has some opinion.

> If yes then I think it is confusing to modify this comment, and the
> comment before the pre-console #defines should mention that the buffer
> is boottime only/short lived etc.

Just in case if something goes really wrong (in theory it shouldn't,
but in practice you know...) it is still somewhat safer to keep the
buffer in its own dedicated area and keep everything else out.
 
> If no then I'm not sure putting a "u-boot managed" buffer in the middle
> of the "user managed" load space is a good idea, since it could lead to
> odd/hard to debug corruptions etc if the kernel was >15M.
>
> Either way I think it would be better to put this buffer somewhere else
> entirely since it isn't really the same as these things.

In a hypothetical scenario of having neither serial console nor
hdmi/lcd/vga console available, the user managed code could probably
dump the pre-console buffer to the SD card and provide some
rudimentary debugging aid. Yes, hardly anyone would ever do this.

If the u-boot log could be somehow passed to the kernel and show in
dmesg, that would be in fact quite useful in my opinion. But this is
well out of scope of discussing the current patch.

> 
> >   */
> >  #define MEM_LAYOUT_ENV_SETTINGS \
> >  	"bootm_size=0xf000000\0" \
> 
> Both u-boot-sunxi#master and #next still have 0x10000000 here, which
> tree is this patch on? Some branch of Hans' tree (with "sunxi:
> sunxi-common.h: Reduce bootm_size to take the framebuffer into account"
> in it) I suppose?

Now the u-boot-sunxi#next branch has "bootm_size=0xf000000" too.

Yes, I was using the Hans' branch with the pending lcd patches,
because I was working with this stuff too.

> Perhaps a better place for the pre-console buffer would be right before
> the framebuffer (or at the top of RAM if no video on the board), with
> modifications to bootm_size or not depending on the answer to the
> original question above.

If this needs any kind of runtime address calculations instead of
compile time constants, then IMHO it becomes unnecessarily complicated.

Anyway. The sunxi part of these changes just needs to assign some
memory area to the pre-console buffer. In the end it does not really
matter which one. The size also does not need to be too large.
For example 1920 * 1080 / (8 * 16) = 16200. It means that only ~16K
of the log buffer can fully cover the FullHD display using the 8x16
font. And this is even assuming no line breaks. I picked 1M only
because it was the smallest unit of the address space allocation in
sunxi-common.h :-)

-- 
Best regards,
Siarhei Siamashka