On Thu, Oct 25, 2012 at 02:27:24PM -0700, Tom Rini wrote: > * PGP Signed by an unknown key > > On 10/25/12 14:19, Allen Martin 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 > > Andrew's recent set of patches for am335x means I do. If I follow > correctly, you're describing the case where >1 port for a driver is > known, we default to say 0 but want to use 1, via the env?
Yes, exactly. I assume that's what the current calls to serial_assign() were supposed to be doing, but weren't. -Allen -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
