On Tue, Mar 10, 2015 at 12:16:07PM +0100, Hans de Goede wrote:
> Hi,
>
> On 03-03-15 14:58, Maxime Ripard wrote:
> >On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 03-03-15 09:22, Maxime Ripard wrote:
> >>>On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
> >>>>>>+/ {
> >>>>>>+ model = "Mele I7 Quad top set box";
> >>>>>>+ compatible = "mele,i7", "allwinner,sun6i-a31";
> >>>>>>+
> >>>>>>+ chosen {
> >>>>>>+ bootargs = "earlyprintk console=ttyS0,115200";
> >>>>>
> >>>>>Using earlyprintk by default is a bad idea if the kernel is configured
> >>>>>with DEBUG_LL support for another SoC.
> >>>>
> >>>>While on this subject, u-boot now sets the chosen/stdout-path property
> >>>>up by default, which means that the kernel will do the right thing by
> >>>>default. So we we really do not need any bootargs= in our dts files.
> >>>
> >>>I just tested that this weekend, and it turned out that the kernel
> >>>couldn't use it so far (ie, no output until init takes over and setup
> >>>a TTY on ttyS0).
> >>>
> >>>Was it working for you?
> >>
> >>Yes, note that the kernel only honors the stdout-path property if
> >>there is no console= argument present if there is a console= argument
> >>present on the kernel cmdline then that will overrule the stdout-path
> >>property
> >
> >Yeah, I removed the bootargs entirely.
> >
> >>Which board did you test with, and what u-boot and kernel version ?
> >
> >I tested it on my A31 hummingbird, with allwinner's u-boot, but with
> >/chosen/stdout-path hardcoded to "serial0:115200n8", with a 4.0-rc1
> >kernel.
>
> I'm not sure if stdout-path supports aliases this is what u-boot is using,
> and which works fine (with 4.0-rc1 kernel):
> "/soc@01c00000/serial@01c28000:115200"I gave that another try, and it worked like a charm, so it really looks like an instance of PEBKAC. > >But it might very well just be me. We just tested it on a Marvell > >board (that uses the same serial driver) this morning and it was fine, > >so I don't think it's really worth worrying about this :) > > > >>>>Currently we've a random mix where we do have bootargs in some, but > >>>>not in most sunxi dts files. I believe we should simply remove it > >>>>everywhere... > >>> > >>>We used to set them in SoCs that are not supported by U-boot yet, and > >>>where the bootloader won't come and patch the DT (A31, A23, A80). > >> > >>Ah, so that is (was) the logic, following that logic we should probably > >>remove bootargs= from at least the a23 and a31 boards (basically > >>from all boards but a80). > > > >I'm not so sure about the A31, since most boards won't even boot by > >default on the SD card > > True. > > > and we have no way to replace U-Boot in NAND > >so far (afaik). But replacing them by stdout-path is a very good > >solution too. > > You mean putting stdout-path in the dts, I'm not sure if I like that, > to me both bootargs and stdout-path are something which should be > left to the bootloader to set. But I understand that when not > using upstream u-boot that may be an issue. I know that some other platforms ask for stdout-path when they review it, because iirc, barebox uses it to know on which console to output its log and export its shell, which is also a valid interpretation of that property, and, contrary to bootargs, doesn't really imply that the bootloader should update it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
