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

Re: [PATCH V2] d-i hd-media support for armhf

On Sun, 2014-11-02 at 15:33 +0100, Karsten Merker wrote:
> On Sat, Nov 01, 2014 at 12:06:55AM -0700, Vagrant Cascadian wrote:
> [d-i hd-media support for armhf, boot script]
> > Overall, it appears to be working quite well. I've thought about
> > creating a similar bootscript for the netboot images.
> > 
> > > +if test -n "${console}"; then
> > > +  setenv bootargs "${bootargs} console=${console}"
> > > +fi
> > 
> > It would seem that the console variable isn't consistant across u-boot
> > platforms. On some (sunxi) it sets both the device and the baudrate
> > (i.e. console=ttyS0,115200), but on many other platforms console only
> > sets the device (i.e. console=ttyS0) and linux then reverts to 9600
> > baud. But the u-boot baudrate is often 115200 with u-boot itself, and
> > set in a baudrate variable. It doesn't seem possible to set a sane
> > default...
> > 
> > So basically this "generic" boot script only works with platforms where
> > the baudrate is included in the "console" variable (or where the
> > baudrate defaults to 9600, to match linux's default, though I think most
> > of the armhf platforms at least default to 115200). *sigh*
> > 
> > Not sure if u-boot's shell has the ability to match contents of
> > variables, so the baudrate could be conditionally added only if not
> > already present.
> AFAICS there is no such functionality in u-boot's commandline
> parser.  Ian, do you perhaps have an idea how to implement this
> in a u-boot script?  Unfortunately the existence of a ${baudrate}
> variable is independent from whether ${console} has the baudrate
> encoded into it or not, so just checking for the existence of
> ${baudrate} does not help in this case.

I'm not thinking of any cunning ideas I'm afraid :-/

Unless console=ttyS0,115200,115200 happens to be safe, but I don't know
that I would suggest relying on that.

This is probably another case where the correct long-game is to drive
some sort of standardisation upstream, we probably aren't the only ones
with this issue.


Reply to: