[meta-xilinx] AMP using Yocto meta-xilinx

[Edward Wingate]

> IOW: you can NOT run an "AMP suitable" binary from JTAG (or vice-versa),
> because of all the above reason.

I don't know, I actually was able to run via JTAG a simple LED blink
program targeted to CPU1.  The BSP is targeted to CPU1 and so is the
application.  It seems if I want an application to be targeted to
CPU1, both the BSP and the application itself (on application project
creation, there is a item to choose a CPU) must be set to run for
CPU1.  I can understand the BSP being fixed to a CPU, but it seems
having the application being fixed to a CPU is troublesome.  I can't
just change the underlying BSP to change target CPU, I must have two
copies of the application code in separate projects, one for each CPU.
Please correct me if I'm wrong about this.  I don't see an obvious way
to change the target CPU for an application once it is created, but I
would be happy to be proven wrong.

Anyway, now that I have an elf that runs on CPU1, I try to have Linux
load it with this in the device tree (taken from the freertos latency
example):
    test: remoteproc-test at 0 {
        compatible = "xlnx,zynq_remoteproc";
        reg = < 0x100000 0x1F00000 >;
        interrupt-parent = <&ps7_scugic_0>;
        interrupts = < 0 37 4 0 38 4 >;
        firmware = "cpu1app.elf";
        ipino = <8>;
        vring0 = <2>;
        vring1 = <3>;
    } ;

On startup, this happens:
[    2.698709] udevd[569]: starting version 182
[    2.815569] CPU1: shutdown
[    2.819163] BUG: using smp_processor_id() in preemptible [00000000]
code: udevd/572
[    2.826797] caller is set_ipi_handler+0x14/0x58
[    2.831252] CPU: 0 PID: 572 Comm: udevd Not tainted 3.14.2-xilinx #1
[    2.837639] [<800147b4>] (unwind_backtrace) from [<800116cc>]
(show_stack+0x10/0x14)
[    2.845344] [<800116cc>] (show_stack) from [<8040e040>]
(dump_stack+0x80/0xc0)
[    2.852527] [<8040e040>] (dump_stack) from [<8020a584>]
(debug_smp_processor_id+0xe8/0xec)
[    2.860785] [<8020a584>] (debug_smp_processor_id) from [<80012f30>]
(set_ipi_handler+0x14/0x58)
[    2.869470] [<80012f30>] (set_ipi_handler) from [<7f014408>]
(zynq_remoteproc_probe+0x1a8/0x3c4 [zynq_remoteproc])
[    2.879804] [<7f014408>] (zynq_remoteproc_probe [zynq_remoteproc])
from [<80255de0>] (platform_drv_probe+0x18/0x4c)
[    2.890206] [<80255de0>] (platform_drv_probe) from [<80254608>]
(driver_probe_device+0x7c/0x21c)
[    2.898973] [<80254608>] (driver_probe_device) from [<80254878>]
(__driver_attach+0x8c/0x90)
[    2.907396] [<80254878>] (__driver_attach) from [<80252c14>]
(bus_for_each_dev+0x6c/0xa0)
[    2.915563] [<80252c14>] (bus_for_each_dev) from [<80253e74>]
(bus_add_driver+0x148/0x1f0)
[    2.923783] [<80253e74>] (bus_add_driver) from [<80254e74>]
(driver_register+0x78/0xf8)
[    2.931782] [<80254e74>] (driver_register) from [<8000881c>]
(do_one_initcall+0xf8/0x154)
[    2.939945] [<8000881c>] (do_one_initcall) from [<8007c3ec>]
(load_module+0x1978/0x1ee0)
[    2.948012] [<8007c3ec>] (load_module) from [<8007caac>]
(SyS_finit_module+0x68/0x78)
[    2.955828] [<8007caac>] (SyS_finit_module) from [<8000e3e0>]
(ret_fast_syscall+0x0/0x30)
[    3.016176]  remoteproc0: 100000.remoteproc-test is available
[    3.021844]  remoteproc0: Note: remoteproc is still under
development and considered experimental.
[    3.119806]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED,
and backward compatibility isn't yet guaranteed.

The LED does not blink as expected, so something is not working.  But
I can't tell what went wrong.
I would have expected more messages about how the load was successful
or something.
I thought I saw elsewhere that when the freertos example app is
loaded, there were more messages displayed.
Is there a way I can perhaps have more debug messages shown?

Just to give more info about my configuration, Linux kernel was
compiled with these flags:
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_HIGHMEM=y
CONFIG_VMSPLIT_2G=y
CONFIG_FW_LOADER=y
CONFIG_ZYNQ_REMOTEPROC=m
CONFIG_RPMSG_OMX=m
CONFIG_RPMSG_FREERTOS_STAT=m

I got these from ug978.  The RPMSG modules probably don't apply in
this case since I'm not using the freertos latency example, but I
don't think they should hurt anything.

Linux on CPU0 is supposed to use the upper 256MB of DDR RAM:
    ps7_ddr_0: memory at 0 {
        device_type = "memory";
        reg = <0x10000000 0x10000000>;
    } ;
Linux does report that it sees 256MB of RAM. I'm not sure how to tell
which 256MB it is using, but I assume the device tree configuration is
valid and Linux is using the 256MB starting at 0x10000000.

The lower 256MB is for CPU1, though in my blink app, I only use 32MB
of it (0x100000 - 0x2000000).  The blink application does access an
AXI GPIO device (not PS GPIO) to toggle the LED pin.  Is there a
possible conflict with Linux in accessing the GPIO device?

Can anyone help me make further progress on this?
Thanks everyone for your help on this so far.