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