* [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED
@ 2005-06-29 18:09 Ladislav Michl
0 siblings, 0 replies; 4+ messages in thread
From: Ladislav Michl @ 2005-06-29 18:09 UTC (permalink / raw)
To: u-boot
Hi,
If "silent" env variable is set GD_FLG_SILENT is added to gd->flags
(in console_init_f). That effectively causes all console output to be
suppresed. That flag also causes nulldev to become outputdev
(in console_init_r). Btw, shouldn't CONFIG_SILENT_CONSOLE depend on
CFG_DEVICE_NULLDEV in this case? Now we are entering into abortboot
(CONFIG_AUTOBOOT_KEYED) and because "silent" env variable is set and
also CONFIG_SILENT_CONSOLE defined console_assign (stdout, "serial"); is
called, doing basicaly nothing, because GD_FLG_SILENT which is still
set prevents any console output.
There are various solutions from this situation, but I'd like first
understand what is CFG_DEVICE_NULLDEV good for when we have GD_FLG_SILENT?
Or better, how should all these three things in question behave?
thanks,
ladis
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED
@ 2005-06-29 22:24 Dave Ellis
2005-06-30 7:56 ` Ladislav Michl
0 siblings, 1 reply; 4+ messages in thread
From: Dave Ellis @ 2005-06-29 22:24 UTC (permalink / raw)
To: u-boot
Ladislav Michl wrote:
> If "silent" env variable is set GD_FLG_SILENT is added to gd->flags
> (in console_init_f). That effectively causes all console output to be
> suppresed. That flag also causes nulldev to become outputdev
> (in console_init_r). Btw, shouldn't CONFIG_SILENT_CONSOLE depend on
> CFG_DEVICE_NULLDEV in this case?
The current implementation of CONFIG_SILENT_CONSOLE needs
CFG_DEVICE_NULLDEV. I suppose a check could be added to
flag the error at build time if CFG_DEVICE_NULLDEV is not
defined.
> Now we are entering into abortboot
> (CONFIG_AUTOBOOT_KEYED) and because "silent" env variable is set and
> also CONFIG_SILENT_CONSOLE defined console_assign (stdout, "serial");
is
> called, doing basicaly nothing, because GD_FLG_SILENT which is still
> set prevents any console output.
In abortboot the "silent" operation is suspended by setting
the console back to serial so you can use the console to
abort the boot. If the boot is aborted GD_FLG_SILENT is
cleared, and the serial console works. If the boot is not
aborted the console is set back to "nulldev" and the boot
continues silently.
> There are various solutions from this situation, but I'd like first
> understand what is CFG_DEVICE_NULLDEV good for when we have
GD_FLG_SILENT?
> Or better, how should all these three things in question behave?
You can boot silently (if "silent" is set), you can
decide to see the output (by removing "silent" from the
environment) and in either case if you abort the boot
the console works. Isn't that exactly what the feature
should do?
Dave Ellis
~~~~~~~~~~~~~~~~~~~~~~~~~~
SIXNET - "Leading the Industrial Ethernet Revolution"
331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA
Tel +1 (518) 877-5173 Fax +1 (518) 877-8346
Email me at: dge at sixnetio.com
Detailed product info: www.sixnetio.com
~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED
2005-06-29 22:24 Dave Ellis
@ 2005-06-30 7:56 ` Ladislav Michl
2005-06-30 21:43 ` Dave Ellis
0 siblings, 1 reply; 4+ messages in thread
From: Ladislav Michl @ 2005-06-30 7:56 UTC (permalink / raw)
To: u-boot
On Wed, Jun 29, 2005 at 06:24:40PM -0400, Dave Ellis wrote:
> The current implementation of CONFIG_SILENT_CONSOLE needs
> CFG_DEVICE_NULLDEV. I suppose a check could be added to
> flag the error at build time if CFG_DEVICE_NULLDEV is not
> defined.
GD_FLG_SILENT flag is checked on every output to console, nulldev device
seems redundant to me.
> In abortboot the "silent" operation is suspended by setting
> the console back to serial so you can use the console to
> abort the boot. If the boot is aborted GD_FLG_SILENT is
> cleared, and the serial console works. If the boot is not
> aborted the console is set back to "nulldev" and the boot
> continues silently.
Indeed, console is set back to serial, but it doesn't help you to see
any output. I would assume you should see at least something like
"Enter password - autoboot in n seconds"
> You can boot silently (if "silent" is set), you can
> decide to see the output (by removing "silent" from the
> environment) and in either case if you abort the boot
> the console works. Isn't that exactly what the feature
> should do?
Yes, that's what I'd expect. But is it done somehow complicated way.
Again, why there is nulldev device when GD_FLG_SILENT is checked on every
console output? Is CONFIG_AUTOBOOT_PROMPT supposed to be displayed even
with "silent" console? Would it break any user setup if I remove
nulldev?
thanks,
ladis
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED
2005-06-30 7:56 ` Ladislav Michl
@ 2005-06-30 21:43 ` Dave Ellis
0 siblings, 0 replies; 4+ messages in thread
From: Dave Ellis @ 2005-06-30 21:43 UTC (permalink / raw)
To: u-boot
Ladislav Michl wrote:
> On Wed, Jun 29, 2005 at 06:24:40PM -0400, Dave Ellis wrote:
> > The current implementation of CONFIG_SILENT_CONSOLE needs
> > CFG_DEVICE_NULLDEV. I suppose a check could be added to
> > flag the error at build time if CFG_DEVICE_NULLDEV is not
> > defined.
>
> GD_FLG_SILENT flag is checked on every output to console, nulldev
device
> seems redundant to me.
Once devices are set up GD_FLG_SILENT would only block
output that implies stdout, not output that specifies it.
I think (I haven't tried it) printf("abc") would be blocked
by GD_FLG_SILENT but fprintf(stdout, "abc") would not.
The fprintf() would be blocked because stdout is nulldev. So
I guess it is mostly redundant, but not for the fprintf() case.
> > In abortboot the "silent" operation is suspended by setting
> > the console back to serial so you can use the console to
[snip]
> Indeed, console is set back to serial, but it doesn't help you to see
> any output. I would assume you should see at least something like
> "Enter password - autoboot in n seconds"
[snip]
> Again, why there is nulldev device when GD_FLG_SILENT is checked on
every
> console output? Is CONFIG_AUTOBOOT_PROMPT supposed to be displayed
even
> with "silent" console? Would it break any user setup if I remove
nulldev?
I think I see the problem. CONFIG_AUTOBOOT_PROMPT should be
displayed, but it isn't because printf() is checking GD_FLG_SILENT.
The cleanest solution I see is to check GD_FLG_SILENT only when
sending directly to the handler, not when sending to the device.
That keeps printf(...) and fprintf(stdout, ...) consistent. Below is
a patch to try:
Dave Ellis
--- u-boot.cvs/common/console.c Thu Mar 31 13:42:16 2005
+++ u-boot.patched/common/console.c Thu Jun 30 16:21:07 2005
@@ -189,16 +189,17 @@ void putc (const char c)
{
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SILENT_CONSOLE
- if (gd->flags & GD_FLG_SILENT)
- return;
-#endif
-
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputc (stdout, c);
} else {
/* Send directly to the handler */
+
+#ifdef CONFIG_SILENT_CONSOLE
+ if (gd->flags & GD_FLG_SILENT)
+ return;
+#endif
+
serial_putc (c);
}
}
@@ -207,16 +208,16 @@ void puts (const char *s)
{
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SILENT_CONSOLE
- if (gd->flags & GD_FLG_SILENT)
- return;
-#endif
-
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs (stdout, s);
} else {
/* Send directly to the handler */
+
+#ifdef CONFIG_SILENT_CONSOLE
+ if (gd->flags & GD_FLG_SILENT)
+ return;
+#endif
serial_puts (s);
}
}
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-06-30 21:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-29 18:09 [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED Ladislav Michl
-- strict thread matches above, loose matches on Subject: below --
2005-06-29 22:24 Dave Ellis
2005-06-30 7:56 ` Ladislav Michl
2005-06-30 21:43 ` Dave Ellis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox