APQ_GPIO_70 not responding to /sys/class/gpio

Ed Sutter

Hi,
We are using APQ_GPIO_107 and APQ_GPIO_70 on a custom board, and noticed this morning that 107 works fine but 70 does not respond to typical gpio commands through /sys/class/gpio. For example...

echo 70 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio70/direction
echo 1 > /sys/class/gpio/gpio70/value

Any idea why?

Ed Sutter

Nevermind... I just saw this post...
https://forum.modalai.com/topic/741/voxl-j13-b2b-clarifications?_=1679325218510

I guess APQ_GPIO_70 is off limits for now...

Alex Kushleyev

Hello Ed,

We recently found a solution to this. GPIO 70, 71, 72 are part of the Audio Subsystem, which is controlled by the ADSP. ADSP is another DSP (separate from SLPI). If you are not using ADSP, then disabling it will fix the issue.

In order to disable the ADSP via Kernel Device Tree, edit the following file to disable the ADSP:

file: msm8996.dtsi

qcom,msm-adsp-loader {
status = "disabled";

and

qcom,lpass@9300000 {
status = "disabled";

The above solution requires rebuilding the kernel for VOXL1 using instructions here : https://gitlab.com/voxl-public/system-image-build/voxl-build

However, I am going to try a simpler solution and see if it works - disabling the ADSP via systemd service - preventing it from starting up. Specifically,

systemctl disable adsp.service and reboot.

You can try it as well.

Alex

Ed Sutter

Thanks Alex! It was a trivial change on our hardware, but good to know.

Alex Kushleyev

OK, no problem. Since this is resolved on your end, i did not verify the simple fix of just disabling ADSP using systemd, but the what did work in the past was disabling the ADSP using systemd AND makding the device tree change I mentioned above.

Just to clarify what is happening, the GPIO can be accessed from CPU and other sub devices in the SoC and in this case if ADSP is enabled, once ADSP starts up, it configures those pins for some audio clock/data functionality and CPU loses control over them. The behavior is such that during the system boot, the CPU initially (first few seconds) seems to have control over the pins, but then ADSP starts up and takes over, and it even sends some clock/data on these pins (a short burst). Therefore, disabling ADSP allows CPU to maintain control over these GPIO pins.

Ed Sutter

@Alex-Kushleyev
Just to clarify, I went ahead and did some preliminary tests, and it appears that just doing the systemctrl disable adsp.service does not allow /sys/class/gpio to control GPIO70.
I did the following before disabling adsp:

/ # echo 70 > /sys/class/gpio/export
/ # echo out > /sys/class/gpio/gpio70/direction
/ # echo 1 > /sys/class/gpio/gpio70/value
/ # cat /sys/class/gpio/gpio70/value
0

Note that I set value to 1, but it didn't stick (expected at this point). I followed this with systemctl disable adsp.service and rebooted. Then I repeated the above steps and still got a 0 for gpio70/value.

Ed Sutter

@Alex-Kushleyev
By the way, the reason I picked GPIO70 was because it appeared to be used for other modems in the voxl-modem script. As a result, I mistakenly took for granted that this pin was "available" for use in bringing up our custom modem module.

It would probably be wise to update that voxl-modem script.

Alex Kushleyev

Thank you for trying disabling the systemd service.. I suspected that it alone might not work..

So, with the service disabled, do you mind just running the following command and see if you have any kernel messages about adsp?

From my notes, i see that under normal boot, you would see the following messages:

dmesg | grep adsp
"[2.477108] systemd[1]: [/lib/systemd/system/adsprpcd.service:11] Failed to parse service restart specifier, ignoring: yes"
"[5.707124] adsp-loader soc:qcom,msm-adsp-loader: adsp_loader_do: scheduling work to load ADSP fw"
"[6.263373] subsys-pil-tz 9300000.qcom,lpass: adsp: Power/Clock ready interrupt received"

Thank you for noting the voxl-modem script, I will check with the team!

Alex

Ed Sutter

Sure... here is the output...

/ # dmesg | grep adsp
[    0.000000] Reserved memory: allocated memory for 'adsp_region' node: base 0x00000000ff800000, size 4 MiB
[    0.000000] Reserved memory: initialized node adsp_region, compatible id shared-dma-pool
[    0.336712] platform soc:qcom,msm-adsprpc-mem: assigned reserved memory node adsp_region
[    0.337300] platform soc:qcom,msm-mdsprpc-mem: assigned reserved memory node adsp_region
[    0.661470] platform soc:qcom,ion:qcom,ion-heap@22: assigned reserved memory node adsp_region
[    0.662328] ION heap adsp created at 0x00000000ff800000 with size 400000
[    0.688677] gdsc_hlos1_vote_lpass_adsp: no parameters
[    1.740246] subsys-pil-tz 9300000.qcom,lpass: for adsp segments only will be dumped.
[    1.786834] fastrpc soc:qcom,msm-adsprpc-mem: for adsp_rh segments only will be dumped.
[    1.788263] adsprpc: channel link type: 0
[    2.438965] systemd[1]: [/lib/systemd/system/adsprpcd.service:11] Failed to parse service restart specifier, ignoring: yes
[    4.909223] SELinux:  Context u:object_r:adsprpcd_file:s0 is not valid (left unmapped).
[    5.451916] adsp-loader soc:qcom,msm-adsp-loader: adsp_loader_do: scheduling work to load ADSP fw
[    5.455155] subsys-pil-tz 9300000.qcom,lpass: adsp: loading from 0x000000008ea00000 to 0x0000000090400000
[    5.912485] subsys-pil-tz 9300000.qcom,lpass: adsp: Brought out of reset
[    5.937106] subsys-pil-tz 9300000.qcom,lpass: adsp: Power/Clock ready interrupt received
[    5.950516] 'opened /dev/adsprpc-smd c 224 0'
[    6.056923] sysmon-qmi: sysmon_clnt_svc_arrive: Connection established between QMI handle and adsp's SSCTL service
[    8.476656] type=1130 audit(1330.153:70): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0-s15:c0.c1023 msg='unit=ads
p comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Note that this is after disabling it...

Ed Sutter

This seems odd...

/ # systemctl status -l adsp.service
● adsp.service - slpi start service
   Loaded: loaded (/etc/initscripts/adsp.sh; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 1970-01-01 00:22:10 UTC; 53 years 2 months ago
  Process: 2032 ExecStart=/etc/initscripts/adsp.sh start (code=exited, status=1/FAILURE)

Jan 01 00:22:06 apq8096 systemd[1]: Starting slpi start service...
Jan 01 00:22:10 apq8096 systemd[1]: adsp.service: Control process exited, code=exited status=1
Jan 01 00:22:10 apq8096 systemd[1]: Failed to start slpi start service.
Jan 01 00:22:10 apq8096 systemd[1]: adsp.service: Unit entered failed state.
Jan 01 00:22:10 apq8096 systemd[1]: adsp.service: Failed with result 'exit-code'.
Jan 01 00:22:10 apq8096 adsp.sh[2032]: Starting adsp: [INFO] Bringing adsp out of reset
Jan 01 00:22:10 apq8096 adsp.sh[2032]: [ERROR] adsp fail to boot

Seems like it tried to startup (despite being disabled) and failed.

Alex Kushleyev

thank you, makes sense.. The systemd service most likely provides some higher level software bridge between CPU and ADSP, but the Kernel starts the ADSP independently of that.

Another thing to note, the ADSP firmware is located in /firmware/image/

I just tried the following command and rebooted and no longer seeing adsp bring-up messages from kernel:

/firmware/image # mv adsp.mdt adsp.mdt.bak

So it seems you can just disable the ADSP this way (the board does not crash).

i also tested setting the output to 1 using your commands it after disabling the adsp firmware, the pin reports 1 (did not check actual signal level)

Ed Sutter

@Alex-Kushleyev
Ok, good to know.
Thanks

Alex Kushleyev

I am not sure about that adsp.service error.. Hmm. Would need to actually look into what it's doing. but it seems like if you just (re)move the firmware, the GPIO works.