-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQia68AAoJENk4IS6UOR1W4NYP/jlbMsXtRojPz7FOVdVSUV+K OK3Pgzc0RD1LMREnHJGRrH42Y5k9s2op0eex/yRLGVjpdyQuM8MykvJ944pDihwX +0Rw8z3oNDg1IeB3R2cgwVCH5vBRGARxr/WdvCQc51uaMDZLwwWM3smHfTvDEeeJ bYIUH9JrAjkpq7DBYCSTq9FR91iJ7hMbLaJjULQaG4Fo64ZBG9A4Llf6+hotADEd 3rHrQN8mJNuYiUYmdbP3B94NNp9+hWXb6r10I8vj2Bb331tBqCHGPOWF4U2h9D2j AHofm8hj22SDTiXNR4SRfGSjqWqc8ZrocaoKxjBTnvlqxgN9+o/w+JNogCJcJ07y zNn73DdxiztgDvoRzWz7oYiI2jF5KGAXVjPRTkY6P5v8Ybh8QF+/CX3NaHjlO7GX VvK3s9AOMqyVz69EZX0OVnaL47WEaz21cG3pA2u595/5kNKrrEbUDEc6tNzLg+vy 5ah1P/g1kqNmKIgN4UtYSKCjCRA4vC5gHs4ixqhPw31aI54YnkbMq/y0SVhvd7Fk iBpsojMQnuHPwRNLtfffqKtkcSMuTxrk2U90KXMg9DSm3cOqPXZgFwfaZH8GXUAV W0Oo7QKpzgoEY4Qm0TjME2/BA/xGh7fBqiu3SAQuE89+w9rGEpQamCkuFFEKYKRt YjHt4C0QHEjwb4kqkINx =D41e -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot