On Thu, 2020-01-16 at 10:56 +0800, Curtis Malainey wrote:
On Thu, Jan 16, 2020 at 4:00 AM Daniel Baluta < daniel.baluta@gmail.com> wrote:
On Wed, Jan 15, 2020 at 12:28 PM Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Wed, 2020-01-15 at 10:51 +0200, Daniel Baluta wrote:
Hello everyone,
I've created a special entry for SOF into Linux Foundation GSoC proposal.
https://wiki.linuxfoundation.org/gsoc/2020-gsoc-sound-open-firmware
I remember last year Intel had their own proposal for SOF. We can still go like this, but just wanted to let you know that my proposal is under Linux Foundation page.
If you have any ideas you can add them to the page.
Looks good to me, this proposal should probably also tie into the GDB code. i.e. GDB polling stub can be initiated on FW crash, then user can connect GDB via Linux to DSP.
So, the gdb polling stub is initiated on DSP side on crash and we design a communication protocol so that gdb can be connected from Linux to DSP to investigate what happened right?
This was the RPMSG integration code that was going to handle the GDB communication correct? Or has the design shifted?
This could come over RPMSG or tunnel directly from userspace GDB to SOF driver via a simple char device, this would be upto the implementer/community.
The status today is :-
1) GDB stub exists, but is not yet invoked on FW exception/panic.
Work that needs done (some of this may have been implemented).
2) GDB stub needs to spin and poll on IPC registers directly instead of using IRQ mode (since we may have IRQ issues that cause crash).
3) GDB stub should have it's own C stack and probably own sections for text, data etc - i.e. try and move it away from runtime code and stacks.
4) GDB communications tunnel in kernel from userspace to SOF driver. Can either be simple char device, RPMSG based.
Thant's it.
Liam