[quote user="Enrique Contreras1"]
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]
Thanks for pointing out that incorrect name on the wiki, I have corrected it.
[quote user="Enrique Contreras1"]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]
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.
[quote user="Enrique Contreras1"]
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).
[/quote]
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