Re: Providing (armhf) u-boot images together with d-i images?
On Wed, Jan 07, 2015 at 06:08:51PM +0000, Ian Campbell wrote:
> > > BTW our kernel now supports the /chosen/stdout-path property in fdt and
> > > will automatically put a console on it.
> >
> > Just to make sure that I understand that correctly: with the
> > u-boot and kernel versions currently in Jessie, there is no need
> > to ever pass a console parameter to the kernel on any platform?
> > Or is this something that was introduced after the u-boot v2014-10
> > release in Jessie?
>
> /chosen/stdout-path is more a function of the kernel and the dtb, I
> don't think u-boot is involved much at all, at it need not be. I suppose
> on platforms where there is a choice of consoles it might auto update
> the stdout-path to reflect where u-boot is outputting it's stuff, but
> you'll get some sort of sane default for the platform either way
> (assuming the dtb is sane).
Hello,
AFAICS the patches to support this functionality code-wise are
included in the Debian kernel package since version 3.16.7-ckt2-1,
but the dtbs we ship do not contain actual definitions of the
/chosen/stdout-path property for the armhf platforms we support in
d-i, which explains why my tests showed no working console
if I have not passed an explicit console parameter on the kernel
commandline.
Some general questions that come to my mind regarding this
functionality:
- What happens if different devices are passed via the console
parameter and via the /chosen/stdout-path? Does one of them
override the other or are both initialized?
- What happens when the same serial device, but with different
options (e.g. baudrate) is defined in the dtb and on the
kernel commandline?
Some of the dtbs (for arm platforms we don't currently support
in d-i) define things like:
chosen {
bootargs = "console=ttyS0,115200n8 earlyprintk";
stdout-path = &uart0;
};
i.e. they define a console device via device-tree path without
specifying a baudrate (which usually means the kernel default
of 9600 baud) and additionally pass a commandline console
option with the same device, but with a baudrate of 115200.
I find that rather confusing.
- AFAIK d-i has some "detect serial console" functionality
which influences the possible language choices. I currently
do not remember whether that works by parsing the console
parameter on the kernel commandline or by using some other
mechanism. If the former, that might pose a problem when
the serial console is set via the dtb.
- If we use (ext|pxe)linux.conf instead of boot.scr and rely on
the dtb to pass the console: what happens for people who run
HDMI console while the dtb defines a serial console? How can
they get d-i to display on the HDMI port? Setting ${console}
does not help in this case as we would not pass it to the
kernel anymore and AFAICS the u-boot in Jessie offers no way to
modify the /chosen/stdout-path property based on the active
u-boot console device.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: