[U-Boot] [RFC PATCH] Pre-console buffer for ARM

Mike Frysinger vapier at gentoo.org
Tue Aug 30 04:50:32 CEST 2011


On Monday, August 29, 2011 21:49:33 Graeme Russ wrote:
> On Tue, Aug 30, 2011 at 11:32 AM, Mike Frysinger wrote:
> > On Monday, August 29, 2011 19:00:46 Graeme Russ wrote:
> >> On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger wrote:
> >> > On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
> >> >> Yes I agree, although if you have more than 1KB of data it might be a
> >> >> bug.
> >> 
> >> I personally don't see the need - I expect the amount of pre-console
> >> output would be faily limited considering that the board should do
> >> everything it can to initialise console as early as possible.
> > 
> > until people hit an early fail and add a lot of debug printf's and then
> > the output gets silently clipped.  it's confusing imo, and i say this
> > having implemented early debug output in other systems (including linux)
> > and seeing how people used/reacted to it.
> 
> We can easily have a 'output clipped' so people know what happened and can
> trim their debugging messages accordingly

much easier said than done.  clipping the head rather than the tail is much 
more often the right default.

> >> > give people a foot and they'll take 1MiB :p
> >> > 
> >> > it's fairly easy as well:
> >> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
> >> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
> >> 
> >> But does that work for non power-of-two buffer sizes...
> > 
> > no, but not that big of a deal.  so you get limited to the last 1KiB,
> > 4KiB, 8KiB, 16KiB, etc... amount of data.
> 
> Until someone doesn't read the documentation and figures they can only
> squeeze 200 bytes out of their L1 cache after making room for gd and stack
> and then tries to print 201 bytes of debug info and trashes either the
> stack or gd and then things start to get a lot weirder than simply having
> their early debug messgaes clipped...

this is really a non-issue as it's trivial to catch at CPP time:
#if (CONFIG_SYS_TMP_CON_BUF_SZ & (CONFIG_SYS_TMP_CON_BUF_SZ - 1))
# error "CONFIG_SYS_TMP_CON_BUF_SZ must be a power-of-two"
#endif

> To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
> and now we only get 128 bytes rather than 200 :( - Better to add another
> long in gd and get 196

my systems dont have nearly the size restrictions yours do, so if you think 
that's better, that's fine by me.  i dont care so much about the internal 
implementation details of the circular buffer ... i only care that it is a 
circular buffer and not one that stops too soon.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110829/92cc8348/attachment.pgp 


More information about the U-Boot mailing list