linaro omap3 image: serial device name change breaks serial console

Yeah; it's a different driver providing the device now; it's specific to OMAP and uses DMA

I think there was discussion about avoid the rename, but it's been in for a while; I think you can configure the kernel to use the regular driver, but then you miss DMA. I think we might have to just live with that rename and go over the transition. :-/

In that case, it seems we need an update to linaro-image-tools to get the kernel boot args set right

Hmm it would be nice if latest linaro-image-tools could keep supporting older images though

Grepping for ttyS2, there are two blocks matching in linaro-media-create:
- the beagle|igep case (console=ttyS2,115200n8 and serialtty=ttyS2)
- a seeminly bogus consoles snippet:
serial_opts=""
if [ "$consoles" ]; then
  for c in ${consoles}; do
    serial_opts="$serial_opts console=$c"
  done
  if [ "$IS_LIVE" -eq 1 ]; then
    serial_opts="$serial_opts serialtty=ttyS2"
  fi
fi

(I think this second snippet is currently bogus in that it hardcodes ttyS2 for all boards.)

I can't think of something elegant right now to handle this change; in an ideal world, we would simply be telling the kernel we want to see console output on the usual serial port, and keep the information about which serial port that is in the kernel itself. We could do something clever in the initramfs or in the rootfs, but not for kernel boot messages :-/

For now, maybe we should just duplicate beagle|igep support into an oldbeagle|oldigep and use ttyS2 in the latter and ttyO2 in the former? alternatively, we could have a new --omap-newserial or --omap-oldserial flag which would select the other tty device.

On Thu, Jan 06, 2011 at 09:18:48AM -0000, Loïc Minier wrote:
> Grepping for ttyS2, there are two blocks matching in linaro-media-create:
> - the beagle|igep case (console=ttyS2,115200n8 and serialtty=ttyS2)
> - a seeminly bogus consoles snippet:
> serial_opts=""
> if [ "$consoles" ]; then
> for c in ${consoles}; do
> serial_opts="$serial_opts console=$c"
> done
> if [ "$IS_LIVE" -eq 1 ]; then
> serial_opts="$serial_opts serialtty=ttyS2"
> fi
> fi

> (I think this second snippet is currently bogus in that it hardcodes
> ttyS2 for all boards.)

If the only part of this that's bogus is the 'ttyS2' hard-coding, does that
mean the kernel does have the capability to send console output to multiple
TTYs? I've never tried this before, but had noticed this bit of code; if it
works, we could just have --dev beagle set both consoles on a transitional
basis, right?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Yes, you can send output to multiple consoles, but only one can get input, and I think the last one wins; also, some messages only make it to one console (I think /dev/console is the problem, it is the last specified console= or current active VT).

serialtty= is handled by some initramfs foo which will create upstart jobs spawning a getty. If you spawn a respawn getty on a non-existing tty, you get regular syslog output that it's not available. We could re-engineer this bit to use udev events to setup gettys on well known consoles if the devices exists?

For anyone else who might be reading this and getting garbage output on the console, lool just pointed out on IRC that the device is now ttyO2 (the letter O as in OMAP), and not the number 0

Guilherme, I'm really not happy with this as a solution. Having to keep the l-m-c and hwpack versions in lockstep is going to be a problem. How do we enable users of lucid and maverick to install beagle hwpacks that use the latest kernel? How do we do that without also breaking their ability to install our already-released hwpacks from 10.11?

Until we have an answer to that, I don't think we can treat this as solved.

This is just an interim solution while the board-specific configs are
not moved to hwpacks -- which I'm planning to work on next. Once that's
done and l-m-c uses them we'll revert this change so that it can, once
again, be used to generate bootable images using the released 10.11
hwpacks.

Remember that the version of l-m-c in Lucid/Maverick can be used to
generate images using the 10.11 hwpacks, but currently there's no
version of l-m-c that can generate a bootable beagle image using the
latest hwpacks.

If you're not happy with just closing this bug before the real solution
is implemented, then I guess we're in agreement, but if you're not happy
with this as an interim solution, I guess we'll need to discuss
alternatives.

On Wed, Jan 19, 2011 at 12:26:25PM -0000, Guilherme Salgado wrote:
> If you're not happy with just closing this bug before the real solution
> is implemented, then I guess we're in agreement

Yep, that's exactly it :)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

As discussed with Loïc yesterday, we'll change our interim solution to look up the kernel version that is installed and if it's less than 2.6.36 we'll use ttyS2, else we'll use ttyO2.