[U-Boot-Users] [PATCH] Allow console input to be disabled

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Mark Jackson]

Added CONFIG_SILENT_CONSOLE_INPUT define.

When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all console input.

---

 common/console.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/common/console.c b/common/console.c
index 1b095b1..ab071e2 100644
--- a/common/console.c
+++ b/common/console.c
@@ -162,6 +162,11 @@ void fprintf (int file, const char *fmt, ...)
 
 int getc (void)
 {
+#if defined(CONFIG_SILENT_CONSOLE) && defined(CONFIG_SILENT_CONSOLE_INPUT)
+	if (gd->flags & GD_FLG_SILENT)
+		return 0;
+#endif
+
 	if (gd->flags & GD_FLG_DEVINIT) {
 		/* Get from the standard input */
 		return fgetc (stdin);
@@ -173,6 +178,11 @@ int getc (void)
 
 int tstc (void)
 {
+#if defined(CONFIG_SILENT_CONSOLE) && defined(CONFIG_SILENT_CONSOLE_INPUT)
+	if (gd->flags & GD_FLG_SILENT)
+		return 0;
+#endif
+
 	if (gd->flags & GD_FLG_DEVINIT) {
 		/* Test the standard input */
 		return ftstc (stdin);

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Haavard Skinnemoen]

Mark Jackson <mpfj@mimc.co.uk> wrote:
> Added CONFIG_SILENT_CONSOLE_INPUT define.
> 
> When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all console input.

Does anyone have an opinion about this? I think it's a nice thing to
have.

Although you should probably update README as well, explaining what
this define means.

Haavard

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Detlev Zundel]

Hi Haavard,

> Mark Jackson <mpfj@mimc.co.uk> wrote:
>> Added CONFIG_SILENT_CONSOLE_INPUT define.
>> 
>> When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all console input.
>
> Does anyone have an opinion about this? I think it's a nice thing to
> have.

Hm, defining this and then "setenv silent=1;saveenv;reset" and we have
lost any chance to access u-boot command line?  This looks pretty
dangerous to me, so I do not particularly like it.

What is the original motivation to skip the input?

Cheers
  Detlev

-- 
I'm  not  one of those who   think Bill Gates is   the devil. I simply
suspect that if Microsoft ever met up with the devil, it wouldn't need
an interpreter.
               --NICHOLAS PETRELEY, Sr. Editor, InfoWorld
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Jerry Van Baren]

Detlev Zundel wrote:
> Hi Haavard,
> 
>> Mark Jackson <mpfj@mimc.co.uk> wrote:
>>> Added CONFIG_SILENT_CONSOLE_INPUT define.
>>>
>>> When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all console input.
>> Does anyone have an opinion about this? I think it's a nice thing to
>> have.
> 
> Hm, defining this and then "setenv silent=1;saveenv;reset" and we have
> lost any chance to access u-boot command line?  This looks pretty
> dangerous to me, so I do not particularly like it.
> 
> What is the original motivation to skip the input?
> 
> Cheers
>   Detlev

Dual-use of a serial port: Mark originally asked about dynamically 
inhibiting u-boot's use of the serial port for normal use, but allowing 
u-boot to use it for development/debug, selected by a jumper:
   <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/44640>
Hardware starved software development. :-/

For completeness, the gmane thread for the patch is here:
   <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/44788>

For what it is worth, I'm with Haavard - it seems useful.  WRT the 
dangerous part - it's intended use is for debug, so presumably it will 
be the developer that locks himself out of the console and will have the 
tools to break back in.  From that POV, it isn't any more dangerous than 
all the other ways a user/developer can brick a board (starting with 
erasing flash ;-).

Best regards,
gvb

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <489AEDF7.9000400@ge.com> you wrote:
>
> For what it is worth, I'm with Haavard - it seems useful.  WRT the 
> dangerous part - it's intended use is for debug, so presumably it will 

It may be intended for debug, but it's available there without warning
for the end user.

> be the developer that locks himself out of the console and will have the 
> tools to break back in.  From that POV, it isn't any more dangerous than 
> all the other ways a user/developer can brick a board (starting with 
> erasing flash ;-).

I think this one is a bit nastier. It's like this rope hanging out of
a black box labeled "silencer". The label  doesn't  mention  that  it
goes "KABOOOOM!" first, before there is a big silence (and a cloud of
dust and a pile of debris).


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Certainly there are things in life that money  can't  buy,  but  it's
very funny - Did you ever try buying them without money? - Ogden Nash

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Mark Jackson]

Wolfgang Denk wrote:
> Dear Jerry Van Baren,
> 
> In message <489AEDF7.9000400@ge.com> you wrote:
>> For what it is worth, I'm with Haavard - it seems useful.  WRT the 
>> dangerous part - it's intended use is for debug, so presumably it will 
> 
> It may be intended for debug, but it's available there without warning
> for the end user.

Is there some "warning" mechanism I should use ?

>> be the developer that locks himself out of the console and will have the 
>> tools to break back in.  From that POV, it isn't any more dangerous than 
>> all the other ways a user/developer can brick a board (starting with 
>> erasing flash ;-).
> 
> I think this one is a bit nastier. It's like this rope hanging out of
> a black box labeled "silencer". The label  doesn't  mention  that  it
> goes "KABOOOOM!" first, before there is a big silence (and a cloud of
> dust and a pile of debris).

I agree that it could all go very wrong, but it was a quick and easy way for me to implement that particular feature.

Does anyone have any suggestions on how to achieve the same outcome in a less "hoist by your own petard" way ?

Mark

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Haavard Skinnemoen]

Wolfgang Denk <wd@denx.de> wrote:
> Dear Jerry Van Baren,
> 
> In message <489AEDF7.9000400@ge.com> you wrote:
> >
> > For what it is worth, I'm with Haavard - it seems useful.  WRT the 
> > dangerous part - it's intended use is for debug, so presumably it will 
> 
> It may be intended for debug, but it's available there without warning
> for the end user.

Hang on...end users can compile custom versions of u-boot now? And
we're somehow responsible for stopping them from bricking their boards
when they go and enable options they don't understand?

How about CONFIG_SKIP_LOW_LEVEL_INIT then? That's _certainly_ dangerous
if you don't know what you're doing.

> > be the developer that locks himself out of the console and will have the 
> > tools to break back in.  From that POV, it isn't any more dangerous than 
> > all the other ways a user/developer can brick a board (starting with 
> > erasing flash ;-).
> 
> I think this one is a bit nastier. It's like this rope hanging out of
> a black box labeled "silencer". The label  doesn't  mention  that  it
> goes "KABOOOOM!" first, before there is a big silence (and a cloud of
> dust and a pile of debris).

The board will most likely still boot, so the "end user" can use other
tools to fix the breakage.

Then again, maybe this thing deserves its own environment variable?
"disable_input" or something?

It certainly deserves to be mentioned in README, as I noted before.

Haavard

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20080811092533.3407704c@hskinnemo-gx745.norway.atmel.com> you wrote:
>
> > It may be intended for debug, but it's available there without warning
> > for the end user.
> 
> Hang on...end users can compile custom versions of u-boot now? And

Actually yes, they can. This is what GPL software is all about:
enabling end users to do exactly that.

> we're somehow responsible for stopping them from bricking their boards
> when they go and enable options they don't understand?

No, we aren't. But that was not the statement.

The problem is the same when the vendor (or  whoever  is  responsible
for setting this option) eneables this feature in a version that will
ship to the end user.

And that was the intention of the patch, if I understand it correctly?

> The board will most likely still boot, so the "end user" can use other
> tools to fix the breakage.

How should he, now that console access is disabled?

> Then again, maybe this thing deserves its own environment variable?
> "disable_input" or something?

And how would you then enable it again? Without being able to input
anything?

> It certainly deserves to be mentioned in README, as I noted before.

The more we discuss about this, the more I tend to simply reject it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... The prejudices people feel about each other disappear  when  then
get to know each other.
	-- Kirk, "Elaan of Troyius", stardate 4372.5

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Wolfgang Denk]

Dear Haavard,

In message <20080811082818.81187248BF@gemini.denx.de> I wrote:
> 
> > The board will most likely still boot, so the "end user" can use other
> > tools to fix the breakage.
> 
> How should he, now that console access is disabled?

Just to give you an example how we handle this in other places:

A similar dangerous operation is changing the console baudrate  -  if
you  set it to something your teminal cannot handle you have the same
problem. U-Boot tries to prevent this, as it enforces you to actually
input something at the new baudrate.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If you want to eat hippopatomus, you've got to pay the  freight."  -
attributed to an IBM guy, about why IBM software uses so much memory

[U-Boot-Users] [PATCH] Allow console input to be disabled

[Haavard Skinnemoen]

Wolfgang Denk <wd@denx.de> wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20080811092533.3407704c@hskinnemo-gx745.norway.atmel.com> you wrote:
> >
> > > It may be intended for debug, but it's available there without warning
> > > for the end user.
> > 
> > Hang on...end users can compile custom versions of u-boot now? And
> 
> Actually yes, they can. This is what GPL software is all about:
> enabling end users to do exactly that.

But if it breaks, they get to keep both pieces.

> > we're somehow responsible for stopping them from bricking their boards
> > when they go and enable options they don't understand?
> 
> No, we aren't. But that was not the statement.
> 
> The problem is the same when the vendor (or  whoever  is  responsible
> for setting this option) eneables this feature in a version that will
> ship to the end user.
> 
> And that was the intention of the patch, if I understand it correctly?

The intention is to allow boards to use a single serial port for two
purposes: Communicating with some other device (which will get really
confused if u-boot interferes) and as a debug port. The user/developer
must have a way to switch between the two roles, and if the first role
is selected, u-boot must stay the hell away from the serial port.

The user will be able to switch between the two by means of an on-board
jumper, so if he needs to interact with u-boot, he can simply flip the
jumper and hook up a PC.

But I guess there's another side-effect from this patch which is
somewhat more nasty: The user can _also_ disable the debug port by
simply setting an environment variable. That might be a bad idea, and
probably not even necessary for Mark's purposes.

So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
use that instead? If set, it will disable both input and output, while
GD_FLG_SILENT will just disable console output.

> > The board will most likely still boot, so the "end user" can use other
> > tools to fix the breakage.
> 
> How should he, now that console access is disabled?

Access the flash directly from Linux?

> > Then again, maybe this thing deserves its own environment variable?
> > "disable_input" or something?
> 
> And how would you then enable it again? Without being able to input
> anything?

Ok, maybe controlling this via an environment variable is a bad idea.

> > It certainly deserves to be mentioned in README, as I noted before.
> 
> The more we discuss about this, the more I tend to simply reject it.

We still need a solution to Mark's problem though.

Haavard

[U-Boot] [U-Boot-Users] [PATCH] Allow console input to be disabled

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20080811131944.500ef1e9@hskinnemo-gx745.norway.atmel.com> you wrote:
> 
> The intention is to allow boards to use a single serial port for two
> purposes: Communicating with some other device (which will get really
> confused if u-boot interferes) and as a debug port. The user/developer
> must have a way to switch between the two roles, and if the first role
> is selected, u-boot must stay the hell away from the serial port.

I understand this. But then, the "silencing" should be done based on
the jumper setting ONLY, without any environment variable setting.

> The user will be able to switch between the two by means of an on-board
> jumper, so if he needs to interact with u-boot, he can simply flip the
> jumper and hook up a PC.

If the user typed "setenv silent=1;saveenv;reset" then hooking  up  a
PC will not help at all because he still has a "silent" board.

> But I guess there's another side-effect from this patch which is
> somewhat more nasty: The user can _also_ disable the debug port by
> simply setting an environment variable. That might be a bad idea, and
> probably not even necessary for Mark's purposes.

Now you get it. That's  what  the  whole  discussion  is  about.  See
Detlev's posting that started it.

> So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
> use that instead? If set, it will disable both input and output, while
> GD_FLG_SILENT will just disable console output.

Sounds much better to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun

[U-Boot] [U-Boot-Users] [PATCH] Allow console input to be disabled

[Haavard Skinnemoen]

Wolfgang Denk <wd@denx.de> wrote:
> > But I guess there's another side-effect from this patch which is
> > somewhat more nasty: The user can _also_ disable the debug port by
> > simply setting an environment variable. That might be a bad idea, and
> > probably not even necessary for Mark's purposes.  
> 
> Now you get it. That's  what  the  whole  discussion  is  about.  See
> Detlev's posting that started it.

Right. I was only thinking about the original purpose of the patch and
forgot that the environment variable wasn't really a necessary part of
the solution.

> > So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
> > use that instead? If set, it will disable both input and output, while
> > GD_FLG_SILENT will just disable console output.  
> 
> Sounds much better to me.

Ok, great. Mark, does this sound good to you?

Haavard

[U-Boot] [U-Boot-Users] [PATCH] Allow console input to be disabled

[Mark Jackson]

Haavard Skinnemoen wrote:
> Wolfgang Denk <wd@denx.de> wrote:
>>> So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
>>> use that instead? If set, it will disable both input and output, while
>>> GD_FLG_SILENT will just disable console output.  
>> Sounds much better to me.
> 
> Ok, great. Mark, does this sound good to you?

Sounds fine.  I didn't mean to cause this much of a "debate" !!

I'll rework in the new flag, and report back.

Thanks
Mark

[U-Boot] [U-Boot-Users] [PATCH] Allow console input to be disabled

[Haavard Skinnemoen]

Mark Jackson <mpfj@mimc.co.uk> wrote:
> Haavard Skinnemoen wrote:
> > Wolfgang Denk <wd@denx.de> wrote:
> >>> So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
> >>> use that instead? If set, it will disable both input and output, while
> >>> GD_FLG_SILENT will just disable console output.  
> >> Sounds much better to me.
> > 
> > Ok, great. Mark, does this sound good to you?
> 
> Sounds fine.  I didn't mean to cause this much of a "debate" !!

If we end up with something everyone's happy with, I'd say the peer
review process worked as intended :-)

> I'll rework in the new flag, and report back.

Thanks.

Haavard