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

[Haavard Skinnemoen]

Wolfgang Denk <wd at denx.de> wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20080811092533.3407704c at 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