08-08-2017 02:43 PM
We are running a typical OpenAMP setup (Petalinux on CPU0 / FreeRTOS on CPU1). SDK version is 2016.2, board is zc706
All the demos work fine (Echo, matrix Mult, etc).
We are trying to initialize the FSCOMMS4 board from the FreeRTOS firmware and it hangs when we load it with the zinq_remoteproc kernel module. If we load the same firmware on CPU1 from the SDK debugger (TCF debugging) the firmware runs fine and initializes the AD9364. If we remove the AD9364 initialization code from the firmware it runs when loaded from the zinq_remoteproc kernel module.
The SPI bus is functional (at least on startup) because we can query the product code from the device and it returns the correct value.
Any help would be appreciated. Thanks
08-08-2017 02:53 PM
What's the zinq_remoteproc kernel module?
A typo or something you created?
08-08-2017 03:38 PM
There are two kernel modules created after enabling OpenAMP in the kernel (UG1186 2016.2 pages 15 - 16). The kernel modules are:
and they are loaded in that order. The rtos-firmware.elf is the FreeRTOS firmware loaded in CPU1. This firmware contains the AD9364 initialization code.
08-09-2017 11:05 AM
I would suggest you to break point and debug BM (CPU1) with JTAG (TCF debugging) to see where and why it stops. I have used this kind of debugging in my OpenAMP investigation, where I had LX running on CPU0 and then stepping through BM application code after(!) it was loaded and started with zynq_remoteproc. I described this briefly in this OpenAMP "chicken or egg" problem forum message (see "JTAG CPU rendezvous" trick).
I found this kind of BM debugging very useful, since it allows me to keep LX on CPU0 alive and running and at the same time from my develop PC step through BM source code, analyze memory, registers and variables.
It is more than year ago that I did this and don't remember all the details I had to do (e.g. Eclipse SDK debug config, compile BM with all debug info included, let debugger know the symbols of BM elf file, ...), but it is definitively doable and worth to try.
08-10-2017 09:39 AM
Thanks for the guidance but this is not exactly what I am seeing.
I do get the /dev/rpmsgX device after loading.
My problem is that right before the kernel module displays the 'remoteproc is up' I lose all SPI functionality. It seems that if the XSpiPs_PolledTransfer function in the xspips.c file cannot read from the spi register it will go into an infinite loop.
Attached is a boot log of the zync_remoteproc kernel module output.
Could this be a memory (amba) problem or could the kernel module be disabling the GIC on CPU1?
On another note...I can 'attach to a running target' using the SDK but when I suspend CPU1 it drops down into the disassembly window without any source. I can see where the code is looping indefinately but is there a way to get a source (c) display so I can verify where it, in fact, is looping?
08-10-2017 11:18 AM
Regarding SPI, I don't know details about how your ZYNQ is configured, but if that SPI port is used by LX (spidev device driver attached to it) than I think there will be problems with sharing it with CPU1 BM application. LX SPI device driver assumes exclusive ownership over it. If you plan to use it from BM CPU1 application than I think you should first remove it from device tree so LX will keep it free.
Regarding attaching to CPU1 and do JTAG debug over BM source files it is definitively possible. I did it +year ago but I don't remember all the details. First the BM ELF must be build with full debug info (no optimizations) and then I think you need to right click on suspended CPU1 and from there specify path to BM ELF file. Once the debugger knows the symbols and path to sources it will show you C source view instead of disassembly view.
08-12-2017 09:01 AM
I re-opened my XSDX 2015.4 project files again I used in my OpenAMP investigation. Attached are screenshots of Debug configuration settings I used for JTAG debug it. Screenshots are of settings that were changed, all other are defaults. ELF (it is an OpenAMP rpmsg echo test using FreeRTOS 8.2.3) was build with full debug info compiler options. I don't have HW at my hands right now so I can not re-run it.