From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][PATCH] Pre-console buffer
Date: Sun, 28 Aug 2011 20:59:32 +1000 [thread overview]
Message-ID: <4E5A1F94.7070802@gmail.com> (raw)
In-Reply-To: <20110828100806.272D6166C8CB@gemini.denx.de>
Hi Wolfgang,
On 28/08/11 20:08, Wolfgang Denk wrote:
> Dear Graeme Russ,
[snip]
>
>> So there are drivers that anticipate generating output before console is
>> initialised - I think we should not put the onus on the driver and move
>> these conditions to printf() in console.c - Unfortunately this could lead
>> to head-scratching when one _thinks_ a printf() should generate an output,
>> but it is squelched (which is what the pre-console buffer is for)
>
> Indeed - which is why this code is only used for debugging drivers in
> certain very special configurations.
So do you think it is worth handling this in printf() as suggested? I do
wonder what unforeseen consequences there can be for an unintended printf()
before console has been initialised. I know that a plain-old 16550 will
just output garbage because the baud rate is not set, but I wonder if other
cases exist where totally unexpected (and unwanted) behaviour will occur
because the hardware is not setup yet.
I think the safe option is to squelch it in printf(), puts() and putc(). At
least then you are only left wondering why something did not print rather
than why you hardware is behaving oddly. And with the pre-console buffer
(if you can squeeze it in) you automagically get those messages as soon as
the console is ready.
Regards,
Graeme
prev parent reply other threads:[~2011-08-28 10:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-27 12:54 [U-Boot] [RFC][PATCH] Pre-console buffer Graeme Russ
2011-08-27 13:48 ` Wolfgang Denk
2011-08-28 0:03 ` Graeme Russ
2011-08-28 10:08 ` Wolfgang Denk
2011-08-28 10:59 ` Graeme Russ [this message]
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=4E5A1F94.7070802@gmail.com \
--to=graeme.russ@gmail.com \
--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