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=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users