public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] Pre-console buffer for ARM
Date: Mon, 29 Aug 2011 22:50:32 -0400	[thread overview]
Message-ID: <201108292250.33200.vapier@gentoo.org> (raw)
In-Reply-To: <CALButCJF1p+60WOLtiJqhcAed-71VxmP2mBqY2wdNURPk5=Q+g@mail.gmail.com>

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 

  reply	other threads:[~2011-08-30  2:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 17:21 [U-Boot] [RFC PATCH] Pre-console buffer for ARM Simon Glass
2011-08-29 19:20 ` Mike Frysinger
2011-08-29 19:42   ` Simon Glass
2011-08-29 20:10     ` Mike Frysinger
2011-08-29 23:00       ` Graeme Russ
2011-08-30  1:32         ` Mike Frysinger
2011-08-30  1:49           ` Graeme Russ
2011-08-30  2:50             ` Mike Frysinger [this message]
2011-08-30  3:12               ` Graeme Russ
2011-08-30  5:17             ` Wolfgang Denk
2011-08-30  5:28               ` Graeme Russ
2011-08-30  9:29                 ` Wolfgang Denk
2011-08-30  9:37                   ` Graeme Russ
2011-08-29 22:49 ` Graeme Russ
2011-08-29 23:01   ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201108292250.33200.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox