Dear Allen Martin, > On Fri, Oct 26, 2012 at 11:39:48AM -0700, Joe Hershberger wrote: > > Hi Marek, > > > > On Fri, Oct 26, 2012 at 5:22 AM, Marek Vasut <ma...@denx.de> wrote: > > > Dear Joe Hershberger, > > > > > >> Hi Allen, > > >> > > >> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amar...@nvidia.com> wrote: > > >> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: > > >> >> Hi, > > >> >> > > >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <ma...@denx.de> wrote: > > >> >> > Dear Simon Glass, > > >> >> > > > >> >> >> Hi, > > >> >> >> > > >> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin > > >> >> >> <amar...@nvidia.com> > > > > > > wrote: > > >> >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > > >> >> >> >> Dear Allen Martin, > > >> >> >> >> > > >> >> >> >> [...] > > >> >> >> >> > > >> >> >> >> > Hi Marek, the change to return value here broke serial > > >> >> >> >> > output on tegra. What I see is that the serial device > > >> >> >> >> > name (s->name) is "eserial0" as set by serial_ns16550.c, > > >> >> >> >> > and the name passed in from the stdout environment is > > >> >> >> >> > "serial" so they don't match and it fails. This always > > >> >> >> >> > used to be ok because the return code didn't indicate > > >> >> >> >> > failure and iomux_doenv() would continue on happily, but > > >> >> >> >> > now it causes iomux_doenv() to fail and no printfs() work > > >> >> >> >> > after that. > > >> >> >> >> > > > >> >> >> >> > Not sure what the right fix is, should stdout really be set > > >> >> >> >> > to "eserial0"? It seems "serial" should mean "the default > > >> >> >> >> > serial device" which for the normal case is the one and > > >> >> >> >> > only device. > > >> >> >> >> > > >> >> >> >> Looking at the source, the obvious course of action is to fix > > >> >> >> >> iomux.c . > > >> >> >> > > > >> >> >> > I've been looking at this call to serial_assign() from iomux.c > > >> >> >> > and I'm not convinced this code does anything meaningful at > > >> >> >> > all. It passes the name of a struct stdio_dev device which > > >> >> >> > serial_assign() then tries to match against the registered > > >> >> >> > struct serial_devices, which will never match. > > >> >> >> > > > >> >> >> > What I don't understand is the case where you have a board > > >> >> >> > that actually has more than one physical serial port and how > > >> >> >> > the mapping from stdio_dev to serial_device happens. > > >> >> >> > > > >> >> >> > Also, looking at the code to cmd_nvedit, I think your change > > >> >> >> > also broke "setenv stdout" for boards that don't define > > >> >> >> > CONFIG_CONSOLE_MUX. We always have this on for tegra, so we > > >> >> >> > don't go down this code path, but it looks identical to the > > >> >> >> > code in iomux.c > > >> >> >> > > >> >> >> Sorry if I missed it - what was the resolution here? Should we > > >> >> >> revert that change? > > >> >> > > > >> >> > Definitelly not. We should fix the iomux.c , possibly by flipping > > >> >> > the inequation mark as a short term solution. > > >> >> > > >> >> OK that's fine. Is someone working on a patch? > > >> > > > >> > I'll send out my proposal for a patch. Unfortunately I don't have a > > >> > board with multiple serial ports to correctly test > > >> > CONFIG_SERIAL_MULTI > > >> > > >> One of the boards I'm working on does this (has more than one). At > > >> least before the serial rework from Marek, the stdout was either the > > >> serial device directly (each serial device was added as a console > > >> device as well) so the serial setting was redundant. You could just > > >> set them directly to the serial port (which is more flexible). > > >> > > >> I had two patches (not sent to ML before Marek made them highly > > >> conflicting) > > > > > > I know, he's such a bastard, always breaking stuff and interfering with > > > other people's work ! > > : > > :) > > : > > >> that take the opposite approach you were, since it > > >> preserves the flexibility. It removed the "serial" setting to each of > > >> the std* variables and instead sets it to the default serial device. > > >> I'll remake that patch on top of the new serial landscape sometime > > >> soon. > > > > > > Actually, I'd like to merge the serial stuff and stdio stuff into one. > > > So "setenv stdX serial" would be replaced with "setenv stdX > > > <serial_driver_name>". I think that's the approach to take. But it'd > > > break many boards. > > > > I think that's fine. We should be able to make it work both ways. In > > other words, as long as there is only one serial device registered, > > then "serial" will be accepted. The actual name of the driver is also > > always accepted. > > Or, ever better we could just say "serial" always maps to > default_serial_console() and that should map exactly to existing > functionality regardless if there is one or more serial devices. Then > any board that wants more precise control can use the name of the > serial driver instead.
So default_serial_console() will return a char * instead of driver pointer ... good. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
