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 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. -- 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
