[meta-xilinx] AMP using Yocto meta-xilinx

[Edward Wingate]

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

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?