Hi, On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <[email protected]> wrote: > Dear Simon Glass, > >> Hi, >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <[email protected]> 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? Regards, Simon > > Best regards, > Marek Vasut _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
