If anyone stumbles upon this thread - the attached script will allow init.d
to start the PRU at boot time which the new pru_rproc driver doesn't seem
to do. In debian 8.7 with 4.4 kernels, it needed a reboot once the kernel
module had loaded because of a bug creating the rpmsg entry in /dev.
Fixed it...
sudo sh -c "echo 'start' > state" from within
/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2
On Tuesday, 28 May 2019 17:25:44 UTC+1, Hugh Frater wrote:
>
> My takeaway from Mark's excellent writeup is that I should be able to
My takeaway from Mark's excellent writeup is that I should be able to copy
my .out file into /lib/firmware with the correct naming convention.
I should then be able to echo 'start' or 'stop' to the correct state file.
Which seems to be located at:
Reading it now, I'll be back... Cheers for all your help up till now
On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote:
>
> On Tue, May 28, 2019 at 10:41 AM Hugh Frater > wrote:
> >
> > Tried both those fixes Robert, no joy. Is it still acceptable practice
> to symlink
Tried both those fixes Robert, no joy. Is it still acceptable practice to
symlink am335x-pru1-fw to our .out file?
Google led me to this post:
http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
Does anyone know what the remoteproc error codes are?
pru_rproc doesn't start the pru's at boot time, I assume this is the new
behaviour in 4.14 with the uBoot overlays. I've updated initramfs since
symlinking my binary to /lib/firmware/am335x-pru1-fw, that hasn't helped.
I've done an
