exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Kevin Hilman]

Hello,

I'm trying to boot next-20140605[1] on my recently arrived Chromebook2
(peach-pi) and was not getting to userspace.  Comparing notes with Doug
Anderson, his was booting just fine, so after some debugging and adding
'clk_ignore_unused' to the command-line, it started booting fine.

So then, I tracked it down to which clock was causing the problems and
found that it's the mau_epll clock gating that's causing the problem,
and leaving it enabled[1] allows me to boot again.

Any ideas what's going on here?  

And in particular, any ideas why it would affect my board and not other
boards like Doug's?

Thanks,

Kevin

[1] Using this defconfig:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig

[2] 
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 61eccf0dd72f..ed175088ee7e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -911,7 +911,7 @@ static struct samsung_gate_clock
exynos5x_gate_clks[] __initdata = {
                        SRC_MASK_TOP2, 24, 0, 0),

        GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
-                       SRC_MASK_TOP7, 20, 0, 0),
+                       SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),

        /* sclk */
        GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Kevin Hilman]

ping for any Samsung folks that might be able to explain this.

On Thu, Jun 5, 2014 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Hello,
>
> I'm trying to boot next-20140605[1] on my recently arrived Chromebook2
> (peach-pi) and was not getting to userspace.  Comparing notes with Doug
> Anderson, his was booting just fine, so after some debugging and adding
> 'clk_ignore_unused' to the command-line, it started booting fine.
>
> So then, I tracked it down to which clock was causing the problems and
> found that it's the mau_epll clock gating that's causing the problem,
> and leaving it enabled[1] allows me to boot again.
>
> Any ideas what's going on here?
>
> And in particular, any ideas why it would affect my board and not other
> boards like Doug's?
>
> Thanks,
>
> Kevin
>
> [1] Using this defconfig:
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig
>
> [2]
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 61eccf0dd72f..ed175088ee7e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -911,7 +911,7 @@ static struct samsung_gate_clock
> exynos5x_gate_clks[] __initdata = {
>                         SRC_MASK_TOP2, 24, 0, 0),
>
>         GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
> -                       SRC_MASK_TOP7, 20, 0, 0),
> +                       SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>
>         /* sclk */
>         GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Shaik Ameer Basha]

Hi Kevin,

We tested on 3 "peach-pi" boards. We are not observing this issue.

Even I tried with the below defconfig mentioned by you. No issues observed.
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig

This is the u-boot version currently we are using.
U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach

Can you provide us more inputs like uboot version or any extra patches
you applied?
Also try removing all power domain nodes from exynos5420.dtsi and
check whether it is reproduced.

Regards,
Shaik Ameer Basha



On Tue, Jun 10, 2014 at 3:21 AM, Kevin Hilman <khilman@linaro.org> wrote:
> ping for any Samsung folks that might be able to explain this.
>
> On Thu, Jun 5, 2014 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote:
>> Hello,
>>
>> I'm trying to boot next-20140605[1] on my recently arrived Chromebook2
>> (peach-pi) and was not getting to userspace.  Comparing notes with Doug
>> Anderson, his was booting just fine, so after some debugging and adding
>> 'clk_ignore_unused' to the command-line, it started booting fine.
>>
>> So then, I tracked it down to which clock was causing the problems and
>> found that it's the mau_epll clock gating that's causing the problem,
>> and leaving it enabled[1] allows me to boot again.
>>
>> Any ideas what's going on here?
>>
>> And in particular, any ideas why it would affect my board and not other
>> boards like Doug's?
>>
>> Thanks,
>>
>> Kevin
>>
>> [1] Using this defconfig:
>> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig
>>
>> [2]
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 61eccf0dd72f..ed175088ee7e 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -911,7 +911,7 @@ static struct samsung_gate_clock
>> exynos5x_gate_clks[] __initdata = {
>>                         SRC_MASK_TOP2, 24, 0, 0),
>>
>>         GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
>> -                       SRC_MASK_TOP7, 20, 0, 0),
>> +                       SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>>
>>         /* sclk */
>>         GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Doug Anderson]

Hi,

On Mon, Jun 9, 2014 at 11:48 PM, Shaik Ameer Basha
<shaik.samsung@gmail.com> wrote:
> Hi Kevin,
>
> We tested on 3 "peach-pi" boards. We are not observing this issue.
>
> Even I tried with the below defconfig mentioned by you. No issues observed.
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig
>
> This is the u-boot version currently we are using.
> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>
> Can you provide us more inputs like uboot version or any extra patches
> you applied?
> Also try removing all power domain nodes from exynos5420.dtsi and
> check whether it is reproduced.

OK, we've narrowed it down so you can reproduce this and debug it...

To reproduce, simply run "sound init" at the U-Boot command prompt
before booting the kernel.  ...or, alternatively, run "mw.l 03810000
1".

Can you please confirm and then send up some patches to fix this?

--

I'm still a little confused about how Javier didn't run into this.
Both Kevin and Javier are (I think) chain-booting nv-U-Boot from a
kernel partition.  It appears that chain-booting U-Boot somehow runs
the sound init code (at least for me).

-Doug

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Javier Martinez Canillas]

Hello Doug,

On 06/10/2014 07:39 PM, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jun 9, 2014 at 11:48 PM, Shaik Ameer Basha
> <shaik.samsung@gmail.com> wrote:
>> Hi Kevin,
>>
>> We tested on 3 "peach-pi" boards. We are not observing this issue.
>>
>> Even I tried with the below defconfig mentioned by you. No issues observed.
>> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel/exynos5_defconfig
>>
>> This is the u-boot version currently we are using.
>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>
>> Can you provide us more inputs like uboot version or any extra patches
>> you applied?
>> Also try removing all power domain nodes from exynos5420.dtsi and
>> check whether it is reproduced.
> 
> OK, we've narrowed it down so you can reproduce this and debug it...
> 
> To reproduce, simply run "sound init" at the U-Boot command prompt
> before booting the kernel.  ...or, alternatively, run "mw.l 03810000
> 1".
> 
> Can you please confirm and then send up some patches to fix this?
> 
> --
> 
> I'm still a little confused about how Javier didn't run into this.
> Both Kevin and Javier are (I think) chain-booting nv-U-Boot from a
> kernel partition.  It appears that chain-booting U-Boot somehow runs
> the sound init code (at least for me).
>

Yes, I did not have this issue before. However... I installed the latest Peach
pit recovery image you provided me and mainline kernel started to hang on boot.
I remembered this thread so tested Kevin's patch which make it boot again.

You said that chain-booting u-boot runs the sound init code but did you try
booting a signed FIT image using the verified u-boot?

I'm asking because I'm see the hang both when chain-booting nv-u-boot from a
kernel partition and booting a signed FIT image with the verified u-boot.

So it seems this is a regression in latest U-boot and I didn't run into this
before due having an older RW U-Boot on my Peach pit?

> -Doug
> 

Best regards,
Javier

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Doug Anderson]

Javier,

On Tue, Jun 10, 2014 at 1:03 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Yes, I did not have this issue before. However... I installed the latest Peach
> pit recovery image you provided me and mainline kernel started to hang on boot.
> I remembered this thread so tested Kevin's patch which make it boot again.
>
> You said that chain-booting u-boot runs the sound init code but did you try
> booting a signed FIT image using the verified u-boot?

Right, I'd bet that it's actually verified boot that's calling the
sound init code (probably just in case it needs to beep at the user).
...so this would happen even without chain booting.  I haven't tried
signing / booting without chain booting, but I can totally believe it
would hang just as easily.


> I'm asking because I'm see the hang both when chain-booting nv-u-boot from a
> kernel partition and booting a signed FIT image with the verified u-boot.
>
> So it seems this is a regression in latest U-boot and I didn't run into this
> before due having an older RW U-Boot on my Peach pit?

You must have had a very old RW U-Boot, possibly one before audio
support was added.  I think we just need to fix this in the kernel so
it doesn't hang.

-Doug

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Tushar Behera]

On 06/11/2014 01:56 AM, Doug Anderson wrote:
> Javier,
> 
> On Tue, Jun 10, 2014 at 1:03 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Yes, I did not have this issue before. However... I installed the latest Peach
>> pit recovery image you provided me and mainline kernel started to hang on boot.
>> I remembered this thread so tested Kevin's patch which make it boot again.
>>
>> You said that chain-booting u-boot runs the sound init code but did you try
>> booting a signed FIT image using the verified u-boot?
> 
> Right, I'd bet that it's actually verified boot that's calling the
> sound init code (probably just in case it needs to beep at the user).
> ...so this would happen even without chain booting.  I haven't tried
> signing / booting without chain booting, but I can totally believe it
> would hang just as easily.
> 
> 
>> I'm asking because I'm see the hang both when chain-booting nv-u-boot from a
>> kernel partition and booting a signed FIT image with the verified u-boot.
>>
>> So it seems this is a regression in latest U-boot and I didn't run into this
>> before due having an older RW U-Boot on my Peach pit?
> 
> You must have had a very old RW U-Boot, possibly one before audio
> support was added.  I think we just need to fix this in the kernel so
> it doesn't hang.
> 
> -Doug
> 

Hi Kevin,

I have posted the fixes[1] in the mailing list. Please test and update.

Changes:
1 patch in drivers/clk/samsung/clk-exynos-audss.c
1 patch in arch/arm/boot/dts/exynos5420.dtsi

For testing audio in Peach-pi,
1 patch in arch/arm/boot/dts/exynos5800-peach-pi.dts

[1] [PATCH 0/3] Fix boot-hang on Peach-pit and Enable audio

-- 
Tushar Behera

exynos5420-peach-pi: linux-next boot fails unless mau_epll left enabled?

[Javier Martinez Canillas]

Hello Tushar,

On 06/11/2014 07:39 AM, Tushar Behera wrote:
> On 06/11/2014 01:56 AM, Doug Anderson wrote:
>> Javier,
>> 
>> On Tue, Jun 10, 2014 at 1:03 PM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> Yes, I did not have this issue before. However... I installed the latest Peach
>>> pit recovery image you provided me and mainline kernel started to hang on boot.
>>> I remembered this thread so tested Kevin's patch which make it boot again.
>>>
>>> You said that chain-booting u-boot runs the sound init code but did you try
>>> booting a signed FIT image using the verified u-boot?
>> 
>> Right, I'd bet that it's actually verified boot that's calling the
>> sound init code (probably just in case it needs to beep at the user).
>> ...so this would happen even without chain booting.  I haven't tried
>> signing / booting without chain booting, but I can totally believe it
>> would hang just as easily.
>> 
>> 
>>> I'm asking because I'm see the hang both when chain-booting nv-u-boot from a
>>> kernel partition and booting a signed FIT image with the verified u-boot.
>>>
>>> So it seems this is a regression in latest U-boot and I didn't run into this
>>> before due having an older RW U-Boot on my Peach pit?
>> 
>> You must have had a very old RW U-Boot, possibly one before audio
>> support was added.  I think we just need to fix this in the kernel so
>> it doesn't hang.
>> 
>> -Doug
>> 
> 
> Hi Kevin,
> 
> I have posted the fixes[1] in the mailing list. Please test and update.
> 
> Changes:
> 1 patch in drivers/clk/samsung/clk-exynos-audss.c
> 1 patch in arch/arm/boot/dts/exynos5420.dtsi
> 
> For testing audio in Peach-pi,
> 1 patch in arch/arm/boot/dts/exynos5800-peach-pi.dts
> 
> [1] [PATCH 0/3] Fix boot-hang on Peach-pit and Enable audio
> 

I tested your patches and after applying Patch 1 and 2, the kernel did not hang
anymore. Both when booting a signed FIT image directly using the verified u-boot
and chain-booting nv-u-boot and booting a uImage.

I'll add Tested-by tags in the original patches threads.

Thanks a lot and best regards,
Javier