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.
Ian.
Reply to: