Failure booting DragonBoard APQ8060 after mach-qcom introduction

Failure booting DragonBoard APQ8060 after mach-qcom introduction

[Linus Walleij]

Hi Kumar,

I used to be able to boot my DragonBoard, which is not the 87* variant but
the 8060 version, as of kernel v3.14. But since commit 8fc1b0f87
"ARM: qcom: Split Qualcomm support into legacy and multiplatform"
it won't work any longer :-(

I used to use msm_defconfig but since that commit use qcom_defconfig.

I use attached device tree and attach the 8660 DTB like that:
cat build-msm8660/arch/arm/boot/dts/qcom-msm8660-surf.dtb >> zImage
I know 8660 is not quite 8060 but it is apparently close enough.
The DTS doesn't seem to mention the modem part anyway.

I don't know if I'm doing something wrong, I have an additional patch
augmenting the meminfo/memblock that comes invalid from the boot
loader, but that is unlikely to be causing this.

The symptom is that not even earlyprints come up if I put some
printascii() in start_kernel.

Any hints? Do you have APQ8060 working on your end?

Yours,
Linus Walleij

Re: Failure booting DragonBoard APQ8060 after mach-qcom introduction

[Linus Walleij]

On Mon, Aug 11, 2014 at 1:21 PM, Linus Walleij <linus.walleij@linaro.org> wrote:

> The symptom is that not even earlyprints come up if I put some
> printascii() in start_kernel.

Bah that was me not realizing that the defaults for DEBUG_UART_PHYS
and DEBUG_UART_VIRT has to be set up properly... now I get the
earlyprints.

It seems to hang in the gsbi driver probe, off to debug.

Yours,
Linus Walleij

Re: Failure booting DragonBoard APQ8060 after mach-qcom introduction

[Linus Walleij]

On Mon, Aug 11, 2014 at 1:42 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 11, 2014 at 1:21 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> The symptom is that not even earlyprints come up if I put some
>> printascii() in start_kernel.
>
> Bah that was me not realizing that the defaults for DEBUG_UART_PHYS
> and DEBUG_UART_VIRT has to be set up properly... now I get the
> earlyprints.
>
> It seems to hang in the gsbi driver probe, off to debug.

It appears that this oneliner gets the kernel booting again:

diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c
index 447458e696a9..1759a3c9140a 100644
--- a/drivers/soc/qcom/qcom_gsbi.c
+++ b/drivers/soc/qcom/qcom_gsbi.c
@@ -57,7 +57,7 @@ static int gsbi_probe(struct platform_device *pdev)
        /* make sure the gsbi control write is not reordered */
        wmb();

-       clk_disable_unprepare(hclk);
+       //clk_disable_unprepare(hclk);

        return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
 }

The kernel hangs during disable/unprepare of the hclk for the GSBI.
Turning off hclk's could be dangerous if there are vital system
components using the hclk which does not yet have a reference
taken in the kernel, due to missing drivers or similar.

Any ideas?

Yours,
Linus Walleij

Re: Failure booting DragonBoard APQ8060 after mach-qcom introduction

[Srinivas Kandagatla]

Hi Linus,


On 11/08/14 13:49, Linus Walleye wrote:
> On Mon, Aug 11, 2014 at 1:42 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, Aug 11, 2014 at 1:21 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> The symptom is that not even earlyprints come up if I put some
>>> printascii() in start_kernel.
>>
>> Bah that was me not realizing that the defaults for DEBUG_UART_PHYS
>> and DEBUG_UART_VIRT has to be set up properly... now I get the
>> earlyprints.
>>
>> It seems to hang in the gsbi driver probe, off to debug.
>
> It appears that this oneliner gets the kernel booting again:
>
> diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c
> index 447458e696a9..1759a3c9140a 100644
> --- a/drivers/soc/qcom/qcom_gsbi.c
> +++ b/drivers/soc/qcom/qcom_gsbi.c
> @@ -57,7 +57,7 @@ static int gsbi_probe(struct platform_device *pdev)
>          /* make sure the gsbi control write is not reordered */
>          wmb();
>
> -       clk_disable_unprepare(hclk);
> +       //clk_disable_unprepare(hclk);
>
>          return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>   }
>
> The kernel hangs during disable/unprepare of the hclk for the GSBI.
> Turning off hclk's could be dangerous if there are vital system
> components using the hclk which does not yet have a reference
> taken in the kernel, due to missing drivers or similar.
>

There is a patch to fix this 
http://www.spinics.net/lists/linux-arm-msm/msg09633.html

> Any ideas?

IMO, hclk is also used by the serial IP, disabling the clock while its 
being used by early printk would result in hang, I think that's what you 
are seeing.

--srini
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Failure booting DragonBoard APQ8060 after mach-qcom introduction

[Linus Walleij]

On Mon, Aug 11, 2014 at 6:35 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> On 11/08/14 13:49, Linus Walleye wrote:

Hey! :-)

>> The kernel hangs during disable/unprepare of the hclk for the GSBI.
>> Turning off hclk's could be dangerous if there are vital system
>> components using the hclk which does not yet have a reference
>> taken in the kernel, due to missing drivers or similar.
>
> There is a patch to fix this
> http://www.spinics.net/lists/linux-arm-msm/msg09633.html

Awesome, fixes the issue for me,
Tested-by: Linus Walleij <linus.walleij@linaro.org>

Please funnel this as a fix for kernels v3.16+

Yours,
Linus Walleij