Latest mainline (3.16 merge window) does not boot in B2020/STiH416

Latest mainline (3.16 merge window) does not boot in B2020/STiH416

[Daniel Thompson]

Hi Folks

Using the lastest Linus T. mainline it is no longer possible to boot a
B2020/STiH416.

The kernel boots OK and issues UART messages, but the system gets stuck
trying to mount the NFS root filesystem.

Configuration is multi_v7_defconfig+CGROUPS+AUTOFS4_FS+IPV6 (although
the deviations from multi_v7_defconfig should make little difference).

An automated bisect identified the first broken version as:
--- cut here ---
commit 948d8ffb4775705c729501f9a433d05163e2f253
Author: Gabriel FERNANDEZ <gabriel.fernandez@st.com>
Date:   Fri Apr 11 17:07:00 2014 +0200

    ARM: STi: DT: add keyscan for stih416

    Add keyscan support for stih416.
    It is disabled by default given that it is not enabled on all boards.
    Also there are PIOs conflict with already claimed lines.

    Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Giuseppe Condorelli <giuseppe.condorelli@st.com>
    Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
    Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
--- cut here ---

Unfortunately 'git revert 948d8ffb4775705c729501f9a433d05163e2f253' is
insufficient to get things working when merged back to head.

Feel free to ask for any help in resolving the problem.


Daniel.

[STLinux Kernel] Latest mainline (3.16 merge window) does not boot in B2020/STiH416

[Peter Griffin]

Hi Daniel,

On Fri, 13 Jun 2014, Daniel Thompson wrote:
> Hi Folks
> 
> Using the lastest Linus T. mainline it is no longer possible to boot a
> B2020/STiH416.
> 
> The kernel boots OK and issues UART messages, but the system gets stuck
> trying to mount the NFS root filesystem.

Are you booting with  clk_ignore_unused kernel parameter?

Its about at the point you describe that the unused clocks are disabled.

regards,

Peter.

[STLinux Kernel] Latest mainline (3.16 merge window) does not boot in B2020/STiH416

[Daniel Thompson]

On 13/06/14 14:10, Peter Griffin wrote:
> Hi Daniel,
> 
> On Fri, 13 Jun 2014, Daniel Thompson wrote:
>> Hi Folks
>>
>> Using the lastest Linus T. mainline it is no longer possible to boot a
>> B2020/STiH416.
>>
>> The kernel boots OK and issues UART messages, but the system gets stuck
>> trying to mount the NFS root filesystem.
> 
> Are you booting with  clk_ignore_unused kernel parameter?
> 
> Its about at the point you describe that the unused clocks are disabled.

Thanks Pete. Adding this parameter fixes the problem.

Any idea why?

I only ask because there's very little related to the clocks in the
patch bisect picked up (and I did manually check the predecessor before
posting).


Daniel.

[STLinux Kernel] Latest mainline (3.16 merge window) does not boot in B2020/STiH416

[Peter Griffin]

Hi Daniel,

> Thanks Pete. Adding this parameter fixes the problem.
> 
> Any idea why?

Some of the interconnect / core clocks aren't handled properly atm.

I just added some debug in drivers/clk and without clk_ignore_unused
we turn off the clock to DDR :-(

[    9.760022] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.104
[    9.767831] IP-Config: Complete:
[    9.771065]      device=eth0, hwaddr=5a:83:c2:c5:02:0f, ipaddr=192.168.0.104, mask=255.255.255.0, gw=192.168.0.1
[    9.781238]      host=192.168.0.104, domain=, nis-domain=(none)
[    9.787155]      bootserver=0.0.0.0, rootserver=192.168.0.10, rootpath=
[    9.793589]      nameserver0=192.168.0.1
[    9.797718] clk-m-pix-hdmirx-sas clk->name
[    9.801809] clk-s-tmds-fromphy clk->name
[    9.805727] clk-sysin clk->name
[    9.808855] clockgen-gpu-pll clk->name
[    9.812597] clockgen-ddr-pll clk->name
[    9.816340] clockgen-ddr1 clk->name
[    9.819816] clockgen-ddr0 clk->name

regards,

Pete.

Latest mainline (3.16 merge window) does not boot in B2020/STiH416

[Giuseppe CONDORELLI]

Hi Daniel,

what type of messages you have?
Is it a networking issue?

About the inquired patch, as you can easily see via git log, the code
introduced is disabled by default, so I think the keyscan support can be
excluded from the "black" list.
Indeed, if for whatever reason it was enabled and Ethernet disabled (given that its PIOs
conflict with the second ones) it could be a reason of your failures.
One test you can do, other than to check the dt code, is to boot via a usb network cable and
see if the boards mount the nfs filesystem.

Cheers,
Giuseppe

>-----Original Message-----
>From: Daniel Thompson [mailto:daniel.thompson at linaro.org]
>Sent: venerd? 13 giugno 2014 14:59
>To: Gabriel FERNANDEZ
>Cc: Giuseppe CONDORELLI; Gabriel Fernandez; Maxime COQUELIN; Srinivas
>Kandagatla; Patrice CHOTARD; linux-arm-kernel at lists.infradead.org;
>kernel at stlinux.com
>Subject: Latest mainline (3.16 merge window) does not boot in B2020/STiH416
>
>Hi Folks
>
>Using the lastest Linus T. mainline it is no longer possible to boot a
>B2020/STiH416.
>
>The kernel boots OK and issues UART messages, but the system gets stuck
>trying to mount the NFS root filesystem.
>
>Configuration is multi_v7_defconfig+CGROUPS+AUTOFS4_FS+IPV6 (although
>the deviations from multi_v7_defconfig should make little difference).
>
>An automated bisect identified the first broken version as:
>--- cut here ---
>commit 948d8ffb4775705c729501f9a433d05163e2f253
>Author: Gabriel FERNANDEZ <gabriel.fernandez@st.com>
>Date:   Fri Apr 11 17:07:00 2014 +0200
>
>    ARM: STi: DT: add keyscan for stih416
>
>    Add keyscan support for stih416.
>    It is disabled by default given that it is not enabled on all boards.
>    Also there are PIOs conflict with already claimed lines.
>
>    Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>    Signed-off-by: Giuseppe Condorelli <giuseppe.condorelli@st.com>
>    Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
>    Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
>--- cut here ---
>
>Unfortunately 'git revert 948d8ffb4775705c729501f9a433d05163e2f253' is
>insufficient to get things working when merged back to head.
>
>Feel free to ask for any help in resolving the problem.
>
>
>Daniel.