Quantcast
Channel: Embedded Software (Read Only)
Viewing all articles
Browse latest Browse all 25965

Forum Post: RE: IPC3.x application tests problems

$
0
0

[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?

 

 


Viewing all articles
Browse latest Browse all 25965

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>