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