| Message ID | 7hoay6sxjl.fsf@paris.lan (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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",
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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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
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
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
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
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
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 */
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] GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",