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
next prev parent 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