Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Wolfgang Denk [EMAIL PROTECTED] wrote: Dear Jerry Van Baren, In message [EMAIL PROTECTED] 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 KABM! 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Dear Haavard Skinnemoen, In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] ... The prejudices people feel about each other disappear when then get to know each other. -- Kirk, Elaan of Troyius, stardate 4372.5 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Dear Haavard, In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Wolfgang Denk [EMAIL PROTECTED] wrote: Dear Haavard Skinnemoen, In message [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Wolfgang Denk wrote: Dear Jerry Van Baren, In message [EMAIL PROTECTED] 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 KABM! 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Dear Jerry Van Baren, In message [EMAIL PROTECTED] 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 KABM! 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: [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Mark Jackson [EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Allow console input to be disabled
Hi Haavard, Mark Jackson [EMAIL PROTECTED] 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: [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Allow console input to be disabled
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);
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
