From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gerald.vanbaren@ge.com>
Date: Thu, 07 Aug 2008 08:43:35 -0400
Subject: [U-Boot-Users] [PATCH] Allow console input to be disabled
In-Reply-To: <m2myjp10ht.fsf@ohwell.denx.de>
References: <48905BE7.1060402@mimc.co.uk>	<20080807122701.202ee982@hskinnemo-gx745.norway.atmel.com>
	<m2myjp10ht.fsf@ohwell.denx.de>
Message-ID: <489AEDF7.9000400@ge.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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