All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter
Date: Wed, 04 Feb 2015 22:43:01 +0000	[thread overview]
Message-ID: <54D2A075.3020904@cogentembedded.com> (raw)
In-Reply-To: <20150203004146.GB17629@verge.net.au>

Hello.

On 02/03/2015 03:41 AM, Simon Horman wrote:

>>>>> Alt is booted from DT, so chosen/stdout-path is
>>>>> always used, and we can drop the "console=" parameter from chosen/bootargs.

>>>>> This change has a side-effect of changing the console speed from 38400
>>>>> to 115200. This is intentional as 115200 is consistently used on
>>>>> all other shmobile boards.

>>>>     I'd say it's not very practical to change the console's baud rate from
>>>> U-Boot's default

>>> It is consistent with the handling of all other boards with
>>> renesas SoCs that are present in mainline.

>>     Well, not quite: Henninger/Porter is still using 38400.

>  From my point of view that is an oversight which I would have
> resolved had I ever obtained access to the hardware.

    I'll look into that when I have time.

>>>> (AFAIR changing baud rate in U-Boot didn't work)...

>>     That was a recollection from the other board though, I haven't yet tried
>> to do it on the SILK board (and I'm unable to currently as the power supply
>> seems dead).

>>> Perhaps that relates to the version of built of uboot.
>>> On the board I have access to I see:

>>> ver=U-Boot 2013.01.01-g5df9446 (Oct 01 2014 - 14:59:23)

>> U-Boot 2013.01.01 (Oct 17 2014 - 20:59:18)

> It looks like my version has some extra patches (the g5df9446 bit).
> But I could be reading things wrong.

>>> And the following setting altered the baud rate of u-boot (IIRC).

>>> baudrate\x115200

>>     I was going to try that but the board just didn't power up.

    I have switched to another board now (with newer U-Boot flashed),
and I was able to change the baud rate in U-Boot. However, SPL and U-Boot
still start at 38400 and now I'm having garbage instead of the version and 
hardware info. :-(

>>>>> Cc: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
>>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Cc: devicetree@vger.kernel.org
>>>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>>>> ---
>>>>>   arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)

>>>>> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> index 8aec512..f2cf757 100644
>>>>> --- a/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> @@ -20,7 +20,7 @@
>>>>>   	};
>>>>>
>>>>>   	chosen {
>>>>> -		bootargs = "console=ttySC0,38400 ignore_loglevel rw root=/dev/nfs ip=dhcp";
>>>>> +		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";

>>>>     Hm, does this even work as intended? I've tried to boot another R8A7794
>>>> based board and I couldn't get any output with alike command line. Booting
>>>> with 'earlyprintk=serial' has shown that tty0 was enabled as a console which
>>>> is not what we wanted.

    The kernel console started working automagically for me at 115200 on the 
new board.

>>> If you are backporting this change then I believe it has some dependencies
>>> that I can follow up on if it is useful to you.

>>     Contrariwise, I'm forward-porting.

>>> If you are using mainline (e.g. next or renesas-next) then yes,
>>> it works. I have tested it numerous times since the patch was merged.

>>     I'm traditionally using the 'renesas-devel-*' tags.

> If you are using 'renesas-devel-*' tags (and forward porting) then
> you should be in good shape. But if you would like me to verify a particular
> tag I'm happy to do so. It is not unheard of for different instances of
> the same board behave in different ways.

    Thank you, looks like there's no need now.

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter
Date: Thu, 05 Feb 2015 01:43:01 +0300	[thread overview]
Message-ID: <54D2A075.3020904@cogentembedded.com> (raw)
In-Reply-To: <20150203004146.GB17629@verge.net.au>

Hello.

On 02/03/2015 03:41 AM, Simon Horman wrote:

>>>>> Alt is booted from DT, so chosen/stdout-path is
>>>>> always used, and we can drop the "console=" parameter from chosen/bootargs.

>>>>> This change has a side-effect of changing the console speed from 38400
>>>>> to 115200. This is intentional as 115200 is consistently used on
>>>>> all other shmobile boards.

>>>>     I'd say it's not very practical to change the console's baud rate from
>>>> U-Boot's default

>>> It is consistent with the handling of all other boards with
>>> renesas SoCs that are present in mainline.

>>     Well, not quite: Henninger/Porter is still using 38400.

>  From my point of view that is an oversight which I would have
> resolved had I ever obtained access to the hardware.

    I'll look into that when I have time.

>>>> (AFAIR changing baud rate in U-Boot didn't work)...

>>     That was a recollection from the other board though, I haven't yet tried
>> to do it on the SILK board (and I'm unable to currently as the power supply
>> seems dead).

>>> Perhaps that relates to the version of built of uboot.
>>> On the board I have access to I see:

>>> ver=U-Boot 2013.01.01-g5df9446 (Oct 01 2014 - 14:59:23)

>> U-Boot 2013.01.01 (Oct 17 2014 - 20:59:18)

> It looks like my version has some extra patches (the g5df9446 bit).
> But I could be reading things wrong.

>>> And the following setting altered the baud rate of u-boot (IIRC).

>>> baudrate=115200

>>     I was going to try that but the board just didn't power up.

    I have switched to another board now (with newer U-Boot flashed),
and I was able to change the baud rate in U-Boot. However, SPL and U-Boot
still start at 38400 and now I'm having garbage instead of the version and 
hardware info. :-(

>>>>> Cc: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
>>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Cc: devicetree at vger.kernel.org
>>>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>>>> ---
>>>>>   arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)

>>>>> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> index 8aec512..f2cf757 100644
>>>>> --- a/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> @@ -20,7 +20,7 @@
>>>>>   	};
>>>>>
>>>>>   	chosen {
>>>>> -		bootargs = "console=ttySC0,38400 ignore_loglevel rw root=/dev/nfs ip=dhcp";
>>>>> +		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";

>>>>     Hm, does this even work as intended? I've tried to boot another R8A7794
>>>> based board and I couldn't get any output with alike command line. Booting
>>>> with 'earlyprintk=serial' has shown that tty0 was enabled as a console which
>>>> is not what we wanted.

    The kernel console started working automagically for me at 115200 on the 
new board.

>>> If you are backporting this change then I believe it has some dependencies
>>> that I can follow up on if it is useful to you.

>>     Contrariwise, I'm forward-porting.

>>> If you are using mainline (e.g. next or renesas-next) then yes,
>>> it works. I have tested it numerous times since the patch was merged.

>>     I'm traditionally using the 'renesas-devel-*' tags.

> If you are using 'renesas-devel-*' tags (and forward porting) then
> you should be in good shape. But if you would like me to verify a particular
> tag I'm happy to do so. It is not unheard of for different instances of
> the same board behave in different ways.

    Thank you, looks like there's no need now.

WBR, Sergei

WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
To: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Ulrich Hecht
	<ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Geert Uytterhoeven
	<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter
Date: Thu, 05 Feb 2015 01:43:01 +0300	[thread overview]
Message-ID: <54D2A075.3020904@cogentembedded.com> (raw)
In-Reply-To: <20150203004146.GB17629-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

Hello.

On 02/03/2015 03:41 AM, Simon Horman wrote:

>>>>> Alt is booted from DT, so chosen/stdout-path is
>>>>> always used, and we can drop the "console=" parameter from chosen/bootargs.

>>>>> This change has a side-effect of changing the console speed from 38400
>>>>> to 115200. This is intentional as 115200 is consistently used on
>>>>> all other shmobile boards.

>>>>     I'd say it's not very practical to change the console's baud rate from
>>>> U-Boot's default

>>> It is consistent with the handling of all other boards with
>>> renesas SoCs that are present in mainline.

>>     Well, not quite: Henninger/Porter is still using 38400.

>  From my point of view that is an oversight which I would have
> resolved had I ever obtained access to the hardware.

    I'll look into that when I have time.

>>>> (AFAIR changing baud rate in U-Boot didn't work)...

>>     That was a recollection from the other board though, I haven't yet tried
>> to do it on the SILK board (and I'm unable to currently as the power supply
>> seems dead).

>>> Perhaps that relates to the version of built of uboot.
>>> On the board I have access to I see:

>>> ver=U-Boot 2013.01.01-g5df9446 (Oct 01 2014 - 14:59:23)

>> U-Boot 2013.01.01 (Oct 17 2014 - 20:59:18)

> It looks like my version has some extra patches (the g5df9446 bit).
> But I could be reading things wrong.

>>> And the following setting altered the baud rate of u-boot (IIRC).

>>> baudrate=115200

>>     I was going to try that but the board just didn't power up.

    I have switched to another board now (with newer U-Boot flashed),
and I was able to change the baud rate in U-Boot. However, SPL and U-Boot
still start at 38400 and now I'm having garbage instead of the version and 
hardware info. :-(

>>>>> Cc: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> Cc: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
>>>>> ---
>>>>>   arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)

>>>>> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> index 8aec512..f2cf757 100644
>>>>> --- a/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
>>>>> @@ -20,7 +20,7 @@
>>>>>   	};
>>>>>
>>>>>   	chosen {
>>>>> -		bootargs = "console=ttySC0,38400 ignore_loglevel rw root=/dev/nfs ip=dhcp";
>>>>> +		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";

>>>>     Hm, does this even work as intended? I've tried to boot another R8A7794
>>>> based board and I couldn't get any output with alike command line. Booting
>>>> with 'earlyprintk=serial' has shown that tty0 was enabled as a console which
>>>> is not what we wanted.

    The kernel console started working automagically for me at 115200 on the 
new board.

>>> If you are backporting this change then I believe it has some dependencies
>>> that I can follow up on if it is useful to you.

>>     Contrariwise, I'm forward-porting.

>>> If you are using mainline (e.g. next or renesas-next) then yes,
>>> it works. I have tested it numerous times since the patch was merged.

>>     I'm traditionally using the 'renesas-devel-*' tags.

> If you are using 'renesas-devel-*' tags (and forward porting) then
> you should be in good shape. But if you would like me to verify a particular
> tag I'm happy to do so. It is not unheard of for different instances of
> the same board behave in different ways.

    Thank you, looks like there's no need now.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-02-04 22:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04  4:23 [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter Simon Horman
2014-11-04  4:23 ` Simon Horman
2014-11-04  4:23 ` Simon Horman
2014-11-05  5:54 ` Simon Horman
2014-11-05  5:54   ` Simon Horman
2014-11-05  5:54   ` Simon Horman
2015-01-30 21:49 ` Sergei Shtylyov
2015-01-30 21:49   ` Sergei Shtylyov
2015-01-30 21:49   ` Sergei Shtylyov
2015-01-31  4:17   ` Simon Horman
2015-01-31  4:17     ` Simon Horman
2015-01-31  4:17     ` Simon Horman
2015-02-02 22:10     ` Sergei Shtylyov
2015-02-02 22:10       ` Sergei Shtylyov
2015-02-02 22:10       ` Sergei Shtylyov
2015-02-03  0:41       ` Simon Horman
2015-02-03  0:41         ` Simon Horman
2015-02-03  0:41         ` Simon Horman
2015-02-04 22:43         ` Sergei Shtylyov [this message]
2015-02-04 22:43           ` Sergei Shtylyov
2015-02-04 22:43           ` Sergei Shtylyov

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=54D2A075.3020904@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.