[meta-xilinx] Linux/bare-metal AMP interrupt routing

[Nathan Rossi]

On Thu, Jun 11, 2015 at 7:17 AM, Edward Wingate <edwingate8 at gmail.com> wrote:
> On Wed, Jun 10, 2015 at 1:39 PM, Edward Wingate <edwingate8 at gmail.com> wrote:
>> The thing I'm contending with now is the FreeRTOS demo should be
>> writing out to UART0 and I'm not seeing anything there.  When running
>> standalone with a non-AMP BSP, the FreeRTOS demo works perfectly.
>
> I took this out of the device tree and everything is working:
> ps7_uart_0: serial at e0000000 { compatible = "invalid"; };
>
> I added that thinking I don't want Linux using UART0, I want CPU1 to
> use it.  But I guess Linux needs to know about it in order to forward
> the interrupt.
>
> I noticed that when I do "modprobe zynq_remoteproc" to load the CPU1
> firmware and start CPU1, Linux sometimes locks up for a few minutes
> afterwards (the serial terminal is not responsive).  Anyone know what
> could be causing that?
>
> When I attach the debugger and suspend CPU0, I do see it spinning in a
> loop in the disassembly.  Is there a symbol file that Yocto generates
> for the kernel that I can load into the debugger?  For my CPU1
> application, I can load the ELF file as the symbol file and have
> source level debugging.  Can I do something similar with the Linux
> kernel on CPU0?

The vmlinux file should be able to give you the symbols etc. You will
have to dive down into the
tmp/work/<machine>/linux.../image/boot/vmlinux to get it though.

For reference this is the code that handles the irq mapping to the
second CPU: https://github.com/Xilinx/linux-xlnx/blob/master/drivers/remoteproc/zynq_remoteproc.c#L224
It allocates the irq to the remoteproc device, but configures it to
only trigger on the second CPU. So one thing to keep in mind there is
that if the uart driver grabs the interrupt for the uart it might be
whats causing you issues.

Regards,
Nathan