[quote user="Robert Tivy"]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.[/quote]
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".
[quote user="Robert Tivy"]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.[/quote]
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.
[quote user="Robert Tivy"]
Also, you could:
% cat /debug/remoteproc/remoteproc0/trace0
to observe the trace output from the DSP.
[/quote]
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".
[quote user="Robert Tivy"]
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 */
[/quote]
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?