Re: Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device

[Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi,

On 03/10/2015 07:44 PM, Maxime Ripard wrote:
> 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.

Hmm, that is interesting we should probably start doing the same in
all the sunxi dts files, as eventually I would like to move all u-boot
board config to devicetree, so that we only need to maintain dts files
and not both dts files and u-boot board configs.

Regards,

Hans