[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#783074: flash-kernel: improvements to uboot-generic bootscript

On Sun, 2015-06-07 at 10:27 +0100, Ian Campbell wrote:
> On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
> > > The changelog says "some imx systems", do you have a list I could drop
> > > in a comment or should I just say "#Workaround lack of console on
> > > someIMX systems"?
> > 
> > I can confirm that wandboard, cubox-i and hummingboard all default to
> > console=ttymxc0, and several other boards by grepping through u-boot's
> > include/configs. Some actually do "setenv bootargs
> > console=ttymxc0,${baudrate}" before their various boot commands.
> > 
> > If you prefer a more specific comment, maybe "Workaround lack of
> > baudrate included with console on various iMX systems (e.g. wandboard,
> > cubox-i, hummingboard)." An exhaustive list might prove more trouble
> > than it's worth. :)
> For sure!
> I was thinking about this some more and it occurred to me that
> console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
> inheriting the existing baud rate etc settings from the bootloader and
> Just Work(tm).
> That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
> the kernel which is called if no options are given.
> That code has been there since the beginning of git history. Did you try
> with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
> question, I think many people don't realise the baud etc is optional so
> it never gets tried).
> If you've tried without and it doesn't work then either that code isn't
> called when I think, or it is broken. In either case I'm not too
> inclined to investigate further than "does console=ttymxc0 work" and if
> not then apply that bit of the patch.

Actually, the way you've structured the conditions it's utterly harmless
even if it turns out not to be needed, so I committed this bit too.


Reply to: