[FEATURE] GDB polling stub entry for FW crashes

[lgirdwood]

Is your feature request related to a problem? Please describe. There needs to be a Kconfig debug option that invokes the GDB stub in IPC polling mode (i.e.not using scheduler for IPC) upon any FW exception or crash.

Describe the solution you'd like GDB stub will be started in polling mode for any FW crash if enabled in Kconfig. GDB commands over IPC should be polled (by reading IPC registers in a loop) to avoid issues in scheduler. It may also be necessary to use a different stack region (in order to preserve original stack).

[lgirdwood]

Polling IPC now added. Moving to v1.7 for GDB stubb connection to IPC polling methods.

[dbaluta]

@IulianOlaru249 after your is done I think we can have a look at this. @lgirdwood if you have some time can you give us some pointers on how to proceed here.

[dbaluta]

@lgirdwood it looks like most of the infrastructure is already there on firmware side.

So, how should this work? I assume we want to connect with GDB from Host side to DSP. So, I assume that SOF driver in the Linux kernel should expose an interface to gdb, right?

[lgirdwood]

@dbaluta yes, the polling code is there. It needs

1. panic() handler to start GDB stub in FW (if selected in KCONFIG)
2. GDB stub to use polling IPC fro control.
3. kernel gdb tunnel that creates a char device that will tunnel GDB commands through tunnel to FW. I think @cujomalainey has some code that does some of 1,2 and 3 that may be used as a starting point.

[cujomalainey]

i had 2 and 3, i dont think i had 1. @dbaluta for the record this was from the second half of my internship so everything is very hard coded. i created a virtual tty device and had the gdb stub in the firmware communicate over IPC and the kernel would forward those messages to the tty. I was able to do backtrack and that was about the limit due to issues with memory mapping and register windows. Also note this code is from before sound open firmware was even called sound open firmware (i believe it was still called reef then). This branch has the relevant code with occasional merges inbetween my commits. https://github.com/cujomalainey/cros-kernel/compare/feature/gdb-on-dsp

Again i apologize for the commits, they were experimental e.g. https://github.com/cujomalainey/cros-kernel/commit/0779d046eea6ea8306827c3364d51f584f6cf8c9

[dbaluta]

@cujomalainey Thanks! That's good enough for us.

[lgirdwood]

Moving to v1.9 as part of Zephyr integration work.

[kv2019i]

Linking work done with Zephyr in 2022 (never merged upstream):

• Zephyr part - https://github.com/zephyrproject-rtos/zephyr/pull/49077 (example usage https://github.com/nklayman/sof-docs/blob/zephyr-gdb-guide/developer_guides/debugability/gdb/index.rst )
• SOF Linux client https://github.com/nklayman/linux/commit/930457fc8f27a07e87276cbdcf26f4378ff83280

[kv2019i]

Note, 2 weeks to 2.13 stable branch. @lyakh are you looking at this now? 2.13 or 2.14?

[lyakh]

Note, 2 weeks to 2.13 stable branch. @lyakh are you looking at this now? 2.13 or 2.14?

@kv2019i I started looking at it now, yes, but since ATM the available version is only an IPC3 draft, I strongly doubt it that I'd have a mergeable version for IPC4 within 2 weeks. OTOH the SOF change seems to be really small https://github.com/nklayman/sof/commit/cbb3f4d9547f8b72fcf44aac361d24e7213e25a1 but it might also require an IPC4 command set extension. So, the probability of this being ready for 2.13 is rather low, but if it's a high priority task, I could try to work on it with a higher pressure and get an IPC4 equivalent of that change ready in time for the forking.