[meta-xilinx] AMP using Yocto meta-xilinx

[Edward Wingate]

I finally had time this week to make this AMP configuration work on my
custom Zynq board.  With all the info from Nathan's post, I got it to
the point now where Linux can shut down CPU1.  I didn't, however,
create the freertos binary blob, so it is complaining about that.  But
I just wanted to go ahead and try to insert my own binary.

If I have an elf file that was compiled against a BSP targeted for
ps7_cortexa9_0, do I need to re-create the elf compiled against a new
BSP targeted for ps7_cortexa9_1 in order to have Linux load it to run
on CPU1?  I'm having problems doing this.

I created a BSP targeted for ps7_cortexa9_1.  Other than the target
CPU, the only other difference is I added an extra compiler flag
"-DUSE_AMP=1".  But when I re-build my elf referencing this new BSP,
it no longer works when I load via JTAG (just to test it first).  I
also tried it without USE_AMP defined so that BSP's should be
identical except for the target CPU, but that didn't help.

When I debug it, it ends up in EndlessLoop1 in boot.S:

/* this initializes the various processor modes */
_prestart:
_boot:

#if XPAR_CPU_ID==0
/* only allow cpu0 through */
    mrc p15,0,r1,c0,c0,5
    and r1, r1, #0xf
    cmp r1, #0
    beq OKToRun
EndlessLoop0:
    wfe
    b EndlessLoop0

#elif XPAR_CPU_ID==1
/* only allow cpu1 through */
    mrc p15,0,r1,c0,c0,5
    and r1, r1, #0xf
    cmp r1, #1
    beq OKToRun
EndlessLoop1:
    wfe
    b EndlessLoop1
#endif

I guess it never gets the OK to branch to OKToRun.  Anyone know what
I'm doing wrong here?

If I try to use the working elf that was created using the original
BSP targeted to CPU0, will that cause other problems?

Thanks for your help.



On Thu, Jan 29, 2015 at 12:07 AM, Nathan Rossi <nathan.rossi at xilinx.com> wrote:
> Hi Edward,
>
> So I decided to play around and see if I could get it working.
>
> 1. udev is the one doing the autoloading, it has detected a module that matches for the device node. You would probably have to add in a udev rule or blacklist the module to prevent it loading.
> 2. The error you are getting is because the kernel is not actually loading at 0x10000000. And thus overlapping memory between the remoteproc and the kernel. Note the UIMAGE_LOADADDR=0x10008000 in the below configs.
>
> Have a look at the changes I made in this branch: https://github.com/nathanrossi/meta-xilinx/tree/for-edward/remoteproc
>
> I did get it loading the firmware, running and sending messages. However I think the freertos firmware I am using is out-of-sync with the 3.14 linux-xlnx kernel. Things to note, the ipino has to be changed as the kernel wants ipino 6 for itself. This means a change in the device tree as well as in the firmware apps remoteproc_kernel.h (NOTIFY_LINUX_IRQ). I set it to 8. Also see the local.conf additions below:
>
> KERNEL_EXTRA_ARGS_zc702-zynq7 = "UIMAGE_LOADADDR=0x10008000"
> KERNEL_FEATURES += "bsp/zc702-zynq7-amp/remoteproc.scc"
> MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += " \
>         kernel-module-zynq-remoteproc \
>         kernel-module-rpmsg-freertos-statistic \
>         kernel-module-rpmsg-omx \
>         kernel-module-rpmsg-proto \
>         "
> CORE_IMAGE_EXTRA_INSTALL += "freertos-amp latencystat"
>
> I did not commit the freertos firmware blob, build one and copy it under recipes-firmware/freertos-amp/files/freertos for it to build out successfully and embed it into the rootfs.
>
> When booting, you will also need to manually modprobe the 'rpmsg_freertos_statistic' to get the /dev/rpmsg interface going. After which the latencystat app can be used to do some data transfers.
>
> Regards,
> Nathan
>