[meta-xilinx] AMP using Yocto meta-xilinx

[Nathan Rossi]

On Wed, May 20, 2015 at 4:48 AM, Edward Wingate <edwingate8 at gmail.com> wrote:
> Following this blog post:
> http://henryomd.blogspot.com/2015/02/zynq-amp-linux-on-cpu0-and-bare-metal.html,
> I got further:
>
> [    2.718247] udevd[572]: starting version 182
> [    2.845012] CPU1: shutdown
> [    2.848639] BUG: using smp_processor_id() in preemptible [00000000]
> code: udevd/575
> [    2.856266] caller is set_ipi_handler+0x14/0x58
> [    2.860727] CPU: 0 PID: 575 Comm: udevd Not tainted 3.14.2-xilinx #1
> [    2.867097] [<800147b4>] (unwind_backtrace) from [<800116cc>]
> (show_stack+0x10/0x14)
> [    2.874816] [<800116cc>] (show_stack) from [<8040e040>]
> (dump_stack+0x80/0xc0)
> [    2.882001] [<8040e040>] (dump_stack) from [<8020a584>]
> (debug_smp_processor_id+0xe8/0xec)
> [    2.890255] [<8020a584>] (debug_smp_processor_id) from [<80012f30>]
> (set_ipi_handler+0x14/0x58)
> [    2.898947] [<80012f30>] (set_ipi_handler) from [<7f014458>]
> (zynq_remoteproc_probe+0x1a8/0x460 [zynq_remoteproc])
> [    2.909275] [<7f014458>] (zynq_remoteproc_probe [zynq_remoteproc])
> from [<80255de0>] (platform_drv_probe+0x18/0x4c)
> [    2.919683] [<80255de0>] (platform_drv_probe) from [<80254608>]
> (driver_probe_device+0x7c/0x21c)
> [    2.928444] [<80254608>] (driver_probe_device) from [<80254878>]
> (__driver_attach+0x8c/0x90)
> [    2.936874] [<80254878>] (__driver_attach) from [<80252c14>]
> (bus_for_each_dev+0x6c/0xa0)
> [    2.945025] [<80252c14>] (bus_for_each_dev) from [<80253e74>]
> (bus_add_driver+0x148/0x1f0)
> [    2.953257] [<80253e74>] (bus_add_driver) from [<80254e74>]
> (driver_register+0x78/0xf8)
> [    2.961257] [<80254e74>] (driver_register) from [<8000881c>]
> (do_one_initcall+0xf8/0x154)
> [    2.969415] [<8000881c>] (do_one_initcall) from [<8007c3ec>]
> (load_module+0x1978/0x1ee0)
> [    2.977492] [<8007c3ec>] (load_module) from [<8007caac>]
> (SyS_finit_module+0x68/0x78)
> [    2.985299] [<8007caac>] (SyS_finit_module) from [<8000e3e0>]
> (ret_fast_syscall+0x0/0x30)
> [    3.038436]  remoteproc0: 100000.remoteproc-test is available
> [    3.044105]  remoteproc0: Note: remoteproc is still under
> development and considered experimental.
> [    3.129696]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED,
> and backward compatibility isn't yet guaranteed.
> [    3.253705]  remoteproc0: firmware_loading_complete
> [    3.259125]  remoteproc0: powering up 100000.remoteproc-test
> [    3.278338]  remoteproc0: Booting fw image cpu1app.elf, size 66576
> [    3.314648]  remoteproc0: remote processor 100000.remoteproc-test is now up

Hi Edward,

Just looking at that stack trace it appears that the remoteproc driver
is failing to allocate the IPI (the set_ipi_handler is a give away, as
the other functions above it look debug related) they are also known
as SGIs in the Zynq TRM.

It is worth checking whether the IPI number setup in your device tree
is actually free to be allocated for the remoteproc driver. You can
check what is already allocated by the kernel by looking at
/proc/interrupts.

$ cat /proc/interrupts
            CPU0
<snip>
IPI1:          0          0  Timer broadcast interrupts
IPI2:          0          0  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:          0          0  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0

The remoteproc driver uses the ipino from the device tree property
'ipino', pick one that the kernel is not using like the below example.
Keep note that there are only 16 IPI/SGIs (0-15).

test: remoteproc-test at 0 {
  compatible = "xlnx,zynq_remoteproc";
...
  ipino = <8>;
...
} ;

>
> I still get the error "BUG: using smp_processor_id() in preemptible
> [00000000] code" and stack trace though.  And the LED that cpu1 app is
> suppose to toggle isn't doing so.  Is this error one that will prevent
> cpu1 application from fully running?
>
> To get this far, I had to modify the zynq_remoteproc module as
> indicated in the blog post and to add a resource table section in the
> cpu1app elf.  I didn't modify boot.S to mark the DDR sections as
> reserved/cached though.  I may try that next, but it seems like a lot
> of off-the-cuff hacking to get Linux to load an elf to CPU1.  Is there
> a more standard way to get this configured and working?

The remoteproc driver and some of the other AMP related stuff is all
in a state of flux (at least with respect to the linux-xlnx vendor
tree). As Xilinx is moving forward with the OpenAMP project
(https://github.com/OpenAMP/open-amp), it relies on some of the
existing kernel drivers/features like remoteproc. Might be worth a
look, although I am under the impression it is not quite ready just
yet.

Regards,
Nathan

> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx