IPC3.x application tests problems

Enrique Contreras1 said:

1- Could the issue be caused the Host (ARM) doesn't receive the broadcast from the DSP, because the interrupts are not configured correctly in u-boot?

I doubt that u-boot needs to do anything, remoteproc should be able to do what's needed interrupt-wise, since it uses a simple interrupt scheme (i.e., no crossbar as with more complicated devices, such as Keystone).

Enrique Contreras1 said:

2- In file NameServer_daemon.c, where NameServer_setup () is implemented, MESSAGEQ_RPMSG_PORT is a constant with value 61. Is this constant related to the interrupts configuration?

No, it is just a "magic" value that both sides of Ipc have "agreed upon".

Enrique Contreras1 said:

3- Is the "da8xx_remoteproc" used for loading the slave binaries in the dsp? (similar to "slaveloader" application in syslink)

Yes, when you insmod/modprobe da8xx_remoteproc.ko it proceeds to locate the DSP binary in /lib/firmware.  Are you specifying the binary name, e.g.:
    % modprobe da8xx_remoteproc fw_name=messageq_single.xe674
?  This command will cause da8xx_remoteproc.ko to look for /lib/firmware/messageq_single.xe674 on the target system.

Enrique Contreras1 said:

4- How can I see if the slave binary has been correctly loaded in the dsp? Is there some command or something similar?

You could take a look at the remoteproc kernel output on the console when you modprobe da8xx_remoteproc.  If it doesn't appear on the console, you might have better luck with the "dmesg" command.  I don't have an OMAP-L137 available to generate the expected output to show you here, but the output should be somewhat self-explanatory.

Also, you could:
    % cat /debug/remoteproc/remoteproc0/trace0
to observe the trace output from the DSP.

One last inquiry ... have you applied the <ipc_install_dir>/linux/patches/3.8.0/rpmsg-socket.patch to your kernel?  This patch tells the kernel about AF_RPMSG, in particular, in <linux_kernel_dir>/include/linux/socket.h:
    #define AF_RPMSG       40      /* Remote-processor messaging   */

Regards,

- Rob

Robert Tivy said:

Yes, when you insmod/modprobe da8xx_remoteproc.ko it proceeds to locate the DSP binary in /lib/firmware.  Are you specifying the binary name, e.g.:
    % modprobe da8xx_remoteproc fw_name=messageq_single.xe674
?  This command will cause da8xx_remoteproc.ko to look for /lib/firmware/messageq_single.xe674 on the target system.

Yes, in fact, the name of the parameter used for introducing the DSP firmware name is not correct in the TI wiki, because the correct name is  "da8xx_fw_name" and not "fw_name".

Robert Tivy said:

You could take a look at the remoteproc kernel output on the console when you modprobe da8xx_remoteproc.  If it doesn't appear on the console, you might have better luck with the "dmesg" command.  I don't have an OMAP-L137 available to generate the expected output to show you here, but the output should be somewhat self-explanatory.

I have tried to introduce some prink() in some parts of the code in da8xx_remoteproc.c and to rebuild the modules, but I don't obtain any kernel message. Even I've changed the current log level in console using a high level number (for instance current level=8, typing the command "echo 9 > /proc/sys/kernel/printk" , but I don't obtain any message. Neither if I write "dmesg" after mounting the module. Also, I have tested to put those prink() parts of code that should be executed.

Robert Tivy said:

Also, you could:
    % cat /debug/remoteproc/remoteproc0/trace0
to observe the trace output from the DSP.

When I type "cat /debug/remoteproc/remoteproc0/trace0", I notice only exist "/debug/remoteproc". I don't know why, because I've mounted previosly with "mount -t debugfs none /debug".

Robert Tivy said:

One last inquiry ... have you applied the <ipc_install_dir>/linux/patches/3.8.0/rpmsg-socket.patch to your kernel?  This patch tells the kernel about AF_RPMSG, in particular, in <linux_kernel_dir>/include/linux/socket.h:
    #define AF_RPMSG       40      /* Remote-processor messaging   */

Yes, I applied all patches provided. Also, I have checked it.

I have been researching and I have notized that the HOST1CFG register in OMAPL137 is different that in OMAPL138, because although its addresses are the same (0x01c14044), the bit HOST1CFG[0] in OMAPL137 is used for helding the DSP in reset mode (if HOST1CFG[0]=0)  or releasing the DSP for wait in reset mode (if HOST1CFG[0]=1). However, this bit doesn't exist in OMAPL138. (compare registers in http://www.ti.com/lit/ug/spruh92b/spruh92b.pdf and http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf).

I guess this could affect in the remoteproc implementation in the kernel source, and I'm not sure what and where I would have to modify. Could someone help me in that?

Regards,

Quique.

Enrique Contreras1 said:

Yes, in fact, the name of the parameter used for introducing the DSP firmware name is not correct in the TI wiki, because the correct name is  "da8xx_fw_name" and not "fw_name".

Thanks for pointing out that incorrect name on the wiki, I have corrected it.

Enrique Contreras1 said:

When I type "cat /debug/remoteproc/remoteproc0/trace0", I notice only exist "/debug/remoteproc". I don't know why, because I've mounted previosly with "mount -t debugfs none /debug".

Each "instance" directory under /debug/remoteproc (i.e., /debug/remoteproc/remoteproc0) is created when that remoteproc instance has been established.  Since you're not able to establish the instance yet, it's not there.

Enrique Contreras1 said:

I have been researching and I have notized that the HOST1CFG register in OMAPL137 is different that in OMAPL138, because although its addresses are the same (0x01c14044), the bit HOST1CFG[0] in OMAPL137 is used for helding the DSP in reset mode (if HOST1CFG[0]=0)  or releasing the DSP for wait in reset mode (if HOST1CFG[0]=1). However, this bit doesn't exist in OMAPL138. (compare registers in http://www.ti.com/lit/ug/spruh92b/spruh92b.pdf and http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf).

I would hazard to presume that the HOST1CFG[0] bit is actually a read-only status bit for OMAPL137 (contrary to the figure in the doc, which says it's "RW").  da8xx_remoteproc.c would be writing a 0 there (since it ensures that the bottom 10 bits of the boot address are 0).

I was also curious about OMAPL137's CHIPSIG register, which is used to interrupt the DSP and check for an interrupt from the DSP, but it appears to be the same address and functionality as OMAPL138.

I don't know what exactly is causing a problem with da8xx_remoteproc on OMAPL137.  The da8xx_remoteproc support was intended for and tested on the OMAPL138.  In order to determine further what might be wrong, it's essential to see the kernel prints coming from the related modules.  I don't have any advice for you on why you're not able to see any console output or dmesg output, but if you can tackle that issue then I can advise based on the kernel output.

Regards,

- Rob

It seems these modules don't run nothing when I insert then. And maybe for that reason I don't obtain any kernel message in console.

I have another question. Is mandatory including the "rproc_mem" parameter into the "bootargs" parameters? If so, I am not sure about what value I would have to assign it. I am trying to test the software in a davinci-da 830-omapl137 board, which has two ram chips with 32MB each one (in total 64MB). In the board booting, kernel image is loaded in the ram address 0xc0700000 and its size is around 2.15MB. Taking all this in account, which value would be right to assign to "rproc_mem"?