From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
Date: Tue, 10 Mar 2015 12:16:07 +0100 [thread overview]
Message-ID: <54FED277.4040000@redhat.com> (raw)
In-Reply-To: <20150303135847.GH4911@lukather>
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"
> 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.
Regards,
Hans
next prev parent reply other threads:[~2015-03-10 11:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-28 13:48 [PATCH] ARM: sun6i: dt: Add new Mele I7 device codekipper-Re5JQEeQqe8AvxtiuMwx3w
[not found] ` <1425131285-8640-1-git-send-email-codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-03 7:16 ` Maxime Ripard
2015-03-03 7:55 ` Hans de Goede
[not found] ` <54F568F8.1040104-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-03 8:22 ` Maxime Ripard
2015-03-03 13:20 ` Hans de Goede
[not found] ` <54F5B51F.6030609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-03 13:58 ` Maxime Ripard
2015-03-10 11:16 ` Hans de Goede [this message]
[not found] ` <54FED277.4040000-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-10 11:40 ` Ian Campbell
2015-03-10 18:44 ` Maxime Ripard
2015-03-10 22:33 ` Hans de Goede
[not found] ` <54FF714F.4010303-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-11 13:41 ` Maxime Ripard
2015-03-11 14:41 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FED277.4040000@redhat.com \
--to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).