Re: Initial msm8909 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 21, 2017 at 3:58 PM, Will Newton <will.newton@xxxxxxxxx> wrote:
> On Thu, Dec 21, 2017 at 10:01 AM, Will Newton <will.newton@xxxxxxxxx> wrote:
>> On Thu, Dec 21, 2017 at 6:45 AM, Bjorn Andersson
>> <bjorn.andersson@xxxxxxxxxx> 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@xxxxxxxxx> wrote:
>>>> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux