Initial msm8909 support

Initial msm8909 support

[Will Newton]

Hi,

I have a git tree with my initial start at msm8909 support in Linux 4.9 here:

https://bitbucket.org/andromedauk/msm8909-linux

It's based off the Linaro Qualcomm landing team tree (with Android
drivers merged too for no useful reason).

The current state is that pinctrl is pretty much done, regulators are
mostly done, clocks is quite hard to say as I'm not doing a good job
of parsing the docs right now. The serial port works! I've seen the
USB driver enumerate a hub but not tested any further.

Outstanding tasks:

1. Semi-random resets during boot. Occasionally the board will reset
for no obvious reason during boot. I suspect this is something to do
with regulators as it usually seems to be around the time something is
setting voltage and turning on initcall debugging seems to make it
less likely to happen (by slowing the boot).

2. Wifi. The wcnss remoteproc driver loads and starts but the wcn36xx
driver is never probed. I am not 100% sure how this probe is meant to
be triggered but I think the SMD driver should create a channel and
trigger the probe but it never does.

3. Hexagon. It gets to the point of loading firmware but the lk I have
on this board is not capable of booting an image with the firmware in
(~30MB is too large it seems).

4. Graphics. I haven't really got very far into debugging this, but it
uses mdp3 so may be a bit of work.

Any comments would be much appreciated.

Thanks,

Re: Initial msm8909 support

[Will Newton]

On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
> Hi,
>
> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>
> https://bitbucket.org/andromedauk/msm8909-linux
>
> It's based off the Linaro Qualcomm landing team tree (with Android
> drivers merged too for no useful reason).
>
> The current state is that pinctrl is pretty much done, regulators are
> mostly done, clocks is quite hard to say as I'm not doing a good job
> of parsing the docs right now. The serial port works! I've seen the
> USB driver enumerate a hub but not tested any further.
>
> Outstanding tasks:
>
> 1. Semi-random resets during boot. Occasionally the board will reset
> for no obvious reason during boot. I suspect this is something to do
> with regulators as it usually seems to be around the time something is
> setting voltage and turning on initcall debugging seems to make it
> less likely to happen (by slowing the boot).

FWIW these resets go away if I disable the wcnss driver in the dts.

> 2. Wifi. The wcnss remoteproc driver loads and starts but the wcn36xx
> driver is never probed. I am not 100% sure how this probe is meant to
> be triggered but I think the SMD driver should create a channel and
> trigger the probe but it never does.
>
> 3. Hexagon. It gets to the point of loading firmware but the lk I have
> on this board is not capable of booting an image with the firmware in
> (~30MB is too large it seems).
>
> 4. Graphics. I haven't really got very far into debugging this, but it
> uses mdp3 so may be a bit of work.
>
> Any comments would be much appreciated.
>
> Thanks,

Re: Initial msm8909 support

[Will Newton]

On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
> On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>> Hi,
>>
>> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>>
>> https://bitbucket.org/andromedauk/msm8909-linux
>>
>> It's based off the Linaro Qualcomm landing team tree (with Android
>> drivers merged too for no useful reason).
>>
>> The current state is that pinctrl is pretty much done, regulators are
>> mostly done, clocks is quite hard to say as I'm not doing a good job
>> of parsing the docs right now. The serial port works! I've seen the
>> USB driver enumerate a hub but not tested any further.
>>
>> Outstanding tasks:
>>
>> 1. Semi-random resets during boot. Occasionally the board will reset
>> for no obvious reason during boot. I suspect this is something to do
>> with regulators as it usually seems to be around the time something is
>> setting voltage and turning on initcall debugging seems to make it
>> less likely to happen (by slowing the boot).
>
> FWIW these resets go away if I disable the wcnss driver in the dts.

Specifically the code that triggers the reset is the call to
qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
out then the boot seems to be stable. Does anyone have any ideas what
might cause that behaviour?

Thanks,

Re: Initial msm8909 support

[Stephen Boyd]

On 12/19, Will Newton wrote:
> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
> >> Hi,
> >>
> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
> >>
> >> https://bitbucket.org/andromedauk/msm8909-linux
> >>
> >> It's based off the Linaro Qualcomm landing team tree (with Android
> >> drivers merged too for no useful reason).
> >>
> >> The current state is that pinctrl is pretty much done, regulators are
> >> mostly done, clocks is quite hard to say as I'm not doing a good job
> >> of parsing the docs right now. The serial port works! I've seen the
> >> USB driver enumerate a hub but not tested any further.

The bus clks that you're missing aren't typically exposed in
downstream kernels because we don't control the rates of those
clks. We've been putting them into upstream to keep the clk tree
connected to a root. If you can list the clks that are missing I
can give you the info you need.

> >>
> >> Outstanding tasks:
> >>
> >> 1. Semi-random resets during boot. Occasionally the board will reset
> >> for no obvious reason during boot. I suspect this is something to do
> >> with regulators as it usually seems to be around the time something is
> >> setting voltage and turning on initcall debugging seems to make it
> >> less likely to happen (by slowing the boot).
> >
> > FWIW these resets go away if I disable the wcnss driver in the dts.
> 
> Specifically the code that triggers the reset is the call to
> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
> out then the boot seems to be stable. Does anyone have any ideas what
> might cause that behaviour?
> 

The wcnss is probably crashing because some regulator or clk is
not enabled, or voltages need to be bumped up. One idea to debug
would be to make wcnss into a module that you load with modprobe.
Then you can try turning on more regulators, and verify that
they're actually on by dumping the SPMI registers, until you
narrow down what's off that needs to be on. This would also allow
you to confirm the RPM communication is working and regulators
are actually working.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Initial msm8909 support

[Will Newton]

On Tue, Dec 19, 2017 at 7:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 12/19, Will Newton wrote:
>> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>> >>
>> >> https://bitbucket.org/andromedauk/msm8909-linux
>> >>
>> >> It's based off the Linaro Qualcomm landing team tree (with Android
>> >> drivers merged too for no useful reason).
>> >>
>> >> The current state is that pinctrl is pretty much done, regulators are
>> >> mostly done, clocks is quite hard to say as I'm not doing a good job
>> >> of parsing the docs right now. The serial port works! I've seen the
>> >> USB driver enumerate a hub but not tested any further.
>
> The bus clks that you're missing aren't typically exposed in
> downstream kernels because we don't control the rates of those
> clks. We've been putting them into upstream to keep the clk tree
> connected to a root. If you can list the clks that are missing I
> can give you the info you need.

The two main clocks that are missing which are used in msm8916 are:

pcnoc_bfdcd_clk_src
system_noc_bfdcd_clk_src

Which are the parents of the AXI/AHB clocks amongst others. It isn't
clear from the msm8909 register reference what parent to use for
these.

Some of it's a bit of a mystery because there are clocks (registers)
in the 3.10 kernel which are not listed in the doc I have (80-NP408-2x
Rev. C) so it's hard to know if those clocks really should be there or
not and the 3.10 kernel doesn't seem to list parents for these clocks
(at least not in a way I have figured out yet).

>> >>
>> >> Outstanding tasks:
>> >>
>> >> 1. Semi-random resets during boot. Occasionally the board will reset
>> >> for no obvious reason during boot. I suspect this is something to do
>> >> with regulators as it usually seems to be around the time something is
>> >> setting voltage and turning on initcall debugging seems to make it
>> >> less likely to happen (by slowing the boot).
>> >
>> > FWIW these resets go away if I disable the wcnss driver in the dts.
>>
>> Specifically the code that triggers the reset is the call to
>> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
>> out then the boot seems to be stable. Does anyone have any ideas what
>> might cause that behaviour?
>>
>
> The wcnss is probably crashing because some regulator or clk is
> not enabled, or voltages need to be bumped up. One idea to debug
> would be to make wcnss into a module that you load with modprobe.
> Then you can try turning on more regulators, and verify that
> they're actually on by dumping the SPMI registers, until you
> narrow down what's off that needs to be on. This would also allow
> you to confirm the RPM communication is working and regulators
> are actually working.

Thanks, I'll give that a try.

Re: Initial msm8909 support

[Bjorn Andersson]

On Tue 19 Dec 09:30 PST 2017, Will Newton wrote:

> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
> >> Hi,
> >>
> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
> >>
> >> https://bitbucket.org/andromedauk/msm8909-linux
> >>
> >> It's based off the Linaro Qualcomm landing team tree (with Android
> >> drivers merged too for no useful reason).
> >>
> >> The current state is that pinctrl is pretty much done, regulators are
> >> mostly done, clocks is quite hard to say as I'm not doing a good job
> >> of parsing the docs right now. The serial port works! I've seen the
> >> USB driver enumerate a hub but not tested any further.
> >>
> >> Outstanding tasks:
> >>
> >> 1. Semi-random resets during boot. Occasionally the board will reset
> >> for no obvious reason during boot. I suspect this is something to do
> >> with regulators as it usually seems to be around the time something is
> >> setting voltage and turning on initcall debugging seems to make it
> >> less likely to happen (by slowing the boot).
> >
> > FWIW these resets go away if I disable the wcnss driver in the dts.
> 
> Specifically the code that triggers the reset is the call to
> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
> out then the boot seems to be stable. Does anyone have any ideas what
> might cause that behaviour?
> 

It's worth noting that there are two sets of errors that occurs in
qcom_scm_pas_auth_and_reset(); either the implementation of the call
itself fails - typically from the lack of clocking of the crypto block -
or if the call succeeds the ARM core in the WiFi subsystem will start
execute the firmware and this might access hardware with expectations on
what the Linux side has configured.

Looking at the pronto in 8916, the only two pieces that comes to mind is
that either vddmx or vddpx are off; or that there are some other nuances
here that I missed when specifying the associated resources - which
isn't needed on the db410c.

Iirc any issues related to the iris (external RF module) will result in
a controlled crash of the remoteproc, not a full system reset.

Regards,
Bjorn

Re: Initial msm8909 support

[Will Newton]

On Thu, Dec 21, 2017 at 6:45 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Tue 19 Dec 09:30 PST 2017, Will Newton wrote:
>
>> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>> >>
>> >> https://bitbucket.org/andromedauk/msm8909-linux
>> >>
>> >> It's based off the Linaro Qualcomm landing team tree (with Android
>> >> drivers merged too for no useful reason).
>> >>
>> >> The current state is that pinctrl is pretty much done, regulators are
>> >> mostly done, clocks is quite hard to say as I'm not doing a good job
>> >> of parsing the docs right now. The serial port works! I've seen the
>> >> USB driver enumerate a hub but not tested any further.
>> >>
>> >> Outstanding tasks:
>> >>
>> >> 1. Semi-random resets during boot. Occasionally the board will reset
>> >> for no obvious reason during boot. I suspect this is something to do
>> >> with regulators as it usually seems to be around the time something is
>> >> setting voltage and turning on initcall debugging seems to make it
>> >> less likely to happen (by slowing the boot).
>> >
>> > FWIW these resets go away if I disable the wcnss driver in the dts.
>>
>> Specifically the code that triggers the reset is the call to
>> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
>> out then the boot seems to be stable. Does anyone have any ideas what
>> might cause that behaviour?
>>
>
> It's worth noting that there are two sets of errors that occurs in
> qcom_scm_pas_auth_and_reset(); either the implementation of the call
> itself fails - typically from the lack of clocking of the crypto block -
> or if the call succeeds the ARM core in the WiFi subsystem will start
> execute the firmware and this might access hardware with expectations on
> what the Linux side has configured.

The crash is unreliable (not every boot) and async - it doesn't happen
exactly at the time of the scm call but soon after, suggesting it is
the wifi subsystem that starts up and then may crash for some reason.

> Looking at the pronto in 8916, the only two pieces that comes to mind is
> that either vddmx or vddpx are off; or that there are some other nuances
> here that I missed when specifying the associated resources - which
> isn't needed on the db410c.

AFAIK the vddmx (l3) and vddpx (l7) supplies are both setup correctly.
The vddcx supply is not specified but I believe it is s1 which
supplies the CPU core so should always be enabled. I've pasted the
regulator summary on a successful boot (no crash but wcn driver did
not probe) below.

One difference I did notice in 3.10 is that msm8909 is listed as
pronto "v3" and msm8916 is listed as "vt". This seems to mean the
regulators are specified slightly differently:

https://source.codeaurora.org/quic/la/kernel/msm-3.10/tree/drivers/net/wireless/wcnss/wcnss_vreg.c?h=LA.BR.1.2.9-03310-8x09.0#n149

But its using voltage corners which to be honest I don't really understand.


  regulator                      use open bypass voltage current     min     max
-------------------------------------------------------------------------------
 regulator-dummy                  0    1      0     0mV     0mA     0mV     0mV
    a204000.wcnss                                                   0mV     0mV
 vph_pwr                          0   11      0  5000mV     0mA  5000mV  5000mV
    s1                            0    0      0  1300mV     0mA  1300mV  1300mV
    s2                            0    8      0  1850mV     0mA  1850mV  1850mV
       l1                         0    0      0  1000mV     0mA  1000mV  1000mV
       l2                         1    1      0  1200mV     0mA  1200mV  1200mV
          78d9000.phy                                            1200mV  1200mV
       l3                         0    1      0  1287mV     0mA   500mV  1350mV
          a204000.wcnss                                          1287mV  1287mV
       l4                         0    0      0  1800mV     0mA  1800mV  1800mV
       l5                         1    2      0  1800mV     0mA  1800mV  1800mV
          a204000.wcnss:iris                                     1800mV  1800mV
          7824900.sdhci                                          1800mV  1950mV
       l6                         0    1      0  1800mV     0mA  1800mV  1800mV
          1ac8300.dsi-phy                                           0mV     0mV
       l7                         1    3      0  1800mV     0mA  1800mV  1800mV
          a204000.wcnss:iris                                     1800mV  1800mV
          a204000.wcnss                                          1800mV  1800mV
          78d9000.phy                                            1800mV  1800mV
       l10                        0    1      0  1300mV     0mA  1225mV  1350mV
          a204000.wcnss:iris                                     1300mV  1300mV
    l8                            1    1      0  2900mV     0mA  2850mV  2900mV
       7824900.sdhci                                             2900mV  2900mV
    l9                            0    1      0  3300mV     0mA  3000mV  3300mV
       a204000.wcnss:iris                                        3300mV  3300mV
    l11                           0    0      0  1800mV     0mA  1800mV  2950mV
    l12                           0    0      0  1800mV     0mA  1800mV  2950mV
    l13                           1    1      0  3075mV     0mA  3075mV  3075mV
       78d9000.phy                                               3050mV  3300mV
    l14                           0    0      0  1800mV     0mA  1800mV  3000mV
    l15                           0    0      0  1800mV     0mA  1800mV  3000mV
    l17                           0    0      0  2800mV     0mA  2800mV  2850mV
    l18                           0    0      0  2700mV     0mA  2700mV  2700mV

Re: Initial msm8909 support

[Will Newton]

On Thu, Dec 21, 2017 at 10:01 AM, Will Newton <will.newton@gmail.com> wrote:
> On Thu, Dec 21, 2017 at 6:45 AM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>> On Tue 19 Dec 09:30 PST 2017, Will Newton wrote:
>>
>>> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
>>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>>> >> Hi,
>>> >>
>>> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>>> >>
>>> >> https://bitbucket.org/andromedauk/msm8909-linux
>>> >>
>>> >> It's based off the Linaro Qualcomm landing team tree (with Android
>>> >> drivers merged too for no useful reason).
>>> >>
>>> >> The current state is that pinctrl is pretty much done, regulators are
>>> >> mostly done, clocks is quite hard to say as I'm not doing a good job
>>> >> of parsing the docs right now. The serial port works! I've seen the
>>> >> USB driver enumerate a hub but not tested any further.
>>> >>
>>> >> Outstanding tasks:
>>> >>
>>> >> 1. Semi-random resets during boot. Occasionally the board will reset
>>> >> for no obvious reason during boot. I suspect this is something to do
>>> >> with regulators as it usually seems to be around the time something is
>>> >> setting voltage and turning on initcall debugging seems to make it
>>> >> less likely to happen (by slowing the boot).
>>> >
>>> > FWIW these resets go away if I disable the wcnss driver in the dts.
>>>
>>> Specifically the code that triggers the reset is the call to
>>> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
>>> out then the boot seems to be stable. Does anyone have any ideas what
>>> might cause that behaviour?
>>>
>>
>> It's worth noting that there are two sets of errors that occurs in
>> qcom_scm_pas_auth_and_reset(); either the implementation of the call
>> itself fails - typically from the lack of clocking of the crypto block -
>> or if the call succeeds the ARM core in the WiFi subsystem will start
>> execute the firmware and this might access hardware with expectations on
>> what the Linux side has configured.
>
> The crash is unreliable (not every boot) and async - it doesn't happen
> exactly at the time of the scm call but soon after, suggesting it is
> the wifi subsystem that starts up and then may crash for some reason.

I believe I have fixed the problem. I rejigged the reserved memory
regions, adding rmtfs and rfsa regions and moving the wcnss region to
a more aligned address. This allows it to continue to download the NV
firmware and then fail with:

[    7.966472] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
WCNSS Version 1.5 1.2
[   18.451512] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
expected cold boot completion

So I guess I still have some debugging to do here.

I also noticed that there seems to be a race between the wcnss and
iris setup. On some boots I get:

[    3.364742] qcom-wcnss-pil a204000.wcnss: no iris registered
[    3.364751] remoteproc remoteproc0: can't start rproc a204000.wcnss: -22

The iris probe function has not yet assigned the iris pointer at this
point but does later.

Re: Initial msm8909 support

[Will Newton]

On Thu, Dec 21, 2017 at 3:58 PM, Will Newton <will.newton@gmail.com> wrote:
> On Thu, Dec 21, 2017 at 10:01 AM, Will Newton <will.newton@gmail.com> wrote:
>> On Thu, Dec 21, 2017 at 6:45 AM, Bjorn Andersson
>> <bjorn.andersson@linaro.org> wrote:
>>> On Tue 19 Dec 09:30 PST 2017, Will Newton wrote:
>>>
>>>> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
>>>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>>>> >> Hi,
>>>> >>
>>>> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>>>> >>
>>>> >> https://bitbucket.org/andromedauk/msm8909-linux
>>>> >>
>>>> >> It's based off the Linaro Qualcomm landing team tree (with Android
>>>> >> drivers merged too for no useful reason).
>>>> >>
>>>> >> The current state is that pinctrl is pretty much done, regulators are
>>>> >> mostly done, clocks is quite hard to say as I'm not doing a good job
>>>> >> of parsing the docs right now. The serial port works! I've seen the
>>>> >> USB driver enumerate a hub but not tested any further.
>>>> >>
>>>> >> Outstanding tasks:
>>>> >>
>>>> >> 1. Semi-random resets during boot. Occasionally the board will reset
>>>> >> for no obvious reason during boot. I suspect this is something to do
>>>> >> with regulators as it usually seems to be around the time something is
>>>> >> setting voltage and turning on initcall debugging seems to make it
>>>> >> less likely to happen (by slowing the boot).
>>>> >
>>>> > FWIW these resets go away if I disable the wcnss driver in the dts.
>>>>
>>>> Specifically the code that triggers the reset is the call to
>>>> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
>>>> out then the boot seems to be stable. Does anyone have any ideas what
>>>> might cause that behaviour?
>>>>
>>>
>>> It's worth noting that there are two sets of errors that occurs in
>>> qcom_scm_pas_auth_and_reset(); either the implementation of the call
>>> itself fails - typically from the lack of clocking of the crypto block -
>>> or if the call succeeds the ARM core in the WiFi subsystem will start
>>> execute the firmware and this might access hardware with expectations on
>>> what the Linux side has configured.
>>
>> The crash is unreliable (not every boot) and async - it doesn't happen
>> exactly at the time of the scm call but soon after, suggesting it is
>> the wifi subsystem that starts up and then may crash for some reason.
>
> I believe I have fixed the problem. I rejigged the reserved memory
> regions, adding rmtfs and rfsa regions and moving the wcnss region to
> a more aligned address. This allows it to continue to download the NV
> firmware and then fail with:
>
> [    7.966472] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
> WCNSS Version 1.5 1.2
> [   18.451512] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
> expected cold boot completion
>
> So I guess I still have some debugging to do here.

I get a watchdog error if I leave the board up for long enough:

[   69.761944] qcom-wcnss-pil a204000.wcnss: fatal error received:
dog.c:1684:Watchdog detects task starvation
[   69.762014] remoteproc remoteproc0: crash detected in
a204000.wcnss: type fatal error
[   69.770561] remoteproc remoteproc0: handling crash #1 in a204000.wcnss
[   69.778636] remoteproc remoteproc0: recovering a204000.wcnss
[   69.983945] remoteproc remoteproc0: stopped remote processor a204000.wcnss
[   69.984008] remoteproc remoteproc0: powering up a204000.wcnss
[   69.990137] remoteproc remoteproc0: Booting fw image wcnss.mdt, size 924
[   70.647291] remoteproc remoteproc0: remote processor a204000.wcnss is now up
[   71.651533]  remoteproc0:smd-edge: remote side did not enter opening state
[   71.651581] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
failed to create endpoint
[   71.657347] qcom_wcnss_ctrl: probe of
remoteproc0:smd-edge.WCNSS_CTRL.-1.-1 failed with error -12

Re: Initial msm8909 support

[Will Newton]

Hi,

Has anyone seen this error before? It seems the firmware is crashing
but giving little indication why this is.


On Thu, Dec 21, 2017 at 4:02 PM, Will Newton <will.newton@gmail.com> wrote:
> On Thu, Dec 21, 2017 at 3:58 PM, Will Newton <will.newton@gmail.com> wrote:
>> On Thu, Dec 21, 2017 at 10:01 AM, Will Newton <will.newton@gmail.com> wrote:
>>> On Thu, Dec 21, 2017 at 6:45 AM, Bjorn Andersson
>>> <bjorn.andersson@linaro.org> wrote:
>>>> On Tue 19 Dec 09:30 PST 2017, Will Newton wrote:
>>>>
>>>>> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@gmail.com> wrote:
>>>>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@gmail.com> wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here:
>>>>> >>
>>>>> >> https://bitbucket.org/andromedauk/msm8909-linux
>>>>> >>
>>>>> >> It's based off the Linaro Qualcomm landing team tree (with Android
>>>>> >> drivers merged too for no useful reason).
>>>>> >>
>>>>> >> The current state is that pinctrl is pretty much done, regulators are
>>>>> >> mostly done, clocks is quite hard to say as I'm not doing a good job
>>>>> >> of parsing the docs right now. The serial port works! I've seen the
>>>>> >> USB driver enumerate a hub but not tested any further.
>>>>> >>
>>>>> >> Outstanding tasks:
>>>>> >>
>>>>> >> 1. Semi-random resets during boot. Occasionally the board will reset
>>>>> >> for no obvious reason during boot. I suspect this is something to do
>>>>> >> with regulators as it usually seems to be around the time something is
>>>>> >> setting voltage and turning on initcall debugging seems to make it
>>>>> >> less likely to happen (by slowing the boot).
>>>>> >
>>>>> > FWIW these resets go away if I disable the wcnss driver in the dts.
>>>>>
>>>>> Specifically the code that triggers the reset is the call to
>>>>> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call
>>>>> out then the boot seems to be stable. Does anyone have any ideas what
>>>>> might cause that behaviour?
>>>>>
>>>>
>>>> It's worth noting that there are two sets of errors that occurs in
>>>> qcom_scm_pas_auth_and_reset(); either the implementation of the call
>>>> itself fails - typically from the lack of clocking of the crypto block -
>>>> or if the call succeeds the ARM core in the WiFi subsystem will start
>>>> execute the firmware and this might access hardware with expectations on
>>>> what the Linux side has configured.
>>>
>>> The crash is unreliable (not every boot) and async - it doesn't happen
>>> exactly at the time of the scm call but soon after, suggesting it is
>>> the wifi subsystem that starts up and then may crash for some reason.
>>
>> I believe I have fixed the problem. I rejigged the reserved memory
>> regions, adding rmtfs and rfsa regions and moving the wcnss region to
>> a more aligned address. This allows it to continue to download the NV
>> firmware and then fail with:
>>
>> [    7.966472] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
>> WCNSS Version 1.5 1.2
>> [   18.451512] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
>> expected cold boot completion
>>
>> So I guess I still have some debugging to do here.
>
> I get a watchdog error if I leave the board up for long enough:
>
> [   69.761944] qcom-wcnss-pil a204000.wcnss: fatal error received:
> dog.c:1684:Watchdog detects task starvation
> [   69.762014] remoteproc remoteproc0: crash detected in
> a204000.wcnss: type fatal error
> [   69.770561] remoteproc remoteproc0: handling crash #1 in a204000.wcnss
> [   69.778636] remoteproc remoteproc0: recovering a204000.wcnss
> [   69.983945] remoteproc remoteproc0: stopped remote processor a204000.wcnss
> [   69.984008] remoteproc remoteproc0: powering up a204000.wcnss
> [   69.990137] remoteproc remoteproc0: Booting fw image wcnss.mdt, size 924
> [   70.647291] remoteproc remoteproc0: remote processor a204000.wcnss is now up
> [   71.651533]  remoteproc0:smd-edge: remote side did not enter opening state
> [   71.651581] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1:
> failed to create endpoint
> [   71.657347] qcom_wcnss_ctrl: probe of
> remoteproc0:smd-edge.WCNSS_CTRL.-1.-1 failed with error -12