Hello Le Son,

I want to make sure I understand your question. Are you saying that in CASE 1, you are able to observe a blinking LED, but in CASE 2, you do not observe a blinking LED?

CASE 1:
echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc0/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state
echo "b" > /dev/rpmsg_pru30

CASE 2:
echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc0/firmware
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state
echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo "b" > /dev/rpmsg_pru30

Regards,

Nick

Hello,

Case 1: after reboot

echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc0/firmware
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state
echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo "b" > /dev/rpmsg_pru30

--> LED toggle

Case 2: after reboot

echo 'button_led.out' > /sys/class/remoteproc/remoteproc1/firmware             (loading other firmware)

echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc2/firmware

echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo 'start' > /sys/class/remoteproc/remoteproc2/state

echo 'stop' > /sys/class/remoteproc/remoteproc1/state
echo 'stop' > /sys/class/remoteproc/remoteproc2/state

echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc0/firmware
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state
echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo "b" > /dev/rpmsg_pru30

--> LED not toggle

Note that AM335x only has two PRU cores, so at least one of the remoteprocX you used in your above response was not a PRU core.

Please verify which core is which by using a technique like 

cat /sys/kernel/debug/remoteproc/remoteproc*/name

Regards,

Nick

Hello,

This is the result:

root@am335x-evm:/home# cat /sys/kernel/debug/remoteproc/remoteproc*/name
wkup_m3
4a334000.pru
4a338000.pru

I think remoteproc1,remoteproc2 are for PRU0, PRU1. 

Actually, by changing the menuconfig in linux build, I could make 2 remoteproc for PRU only (0 and 1). I tested, but the same issue.

Thank You!

I am still unclear on your exact steps. Is this what you are doing? If not, please correct me.

echo 'button_led.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc2/firmware

echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo 'start' > /sys/class/remoteproc/remoteproc2/state

* button_led behaving as expected *

echo 'stop' > /sys/class/remoteproc/remoteproc1/state

echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'start' > /sys/class/remoteproc/remoteproc1/state

echo "b" > /dev/rpmsg_pru30

Regards,

Nick

Hello,

Your mention is Case 2:

echo 'button_led.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc2/firmware

echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo 'start' > /sys/class/remoteproc/remoteproc2/state

* button_led behaving as expected *

echo 'stop' > /sys/class/remoteproc/remoteproc1/state

echo 'PRU_RPMsg_LED0.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'start' > /sys/class/remoteproc/remoteproc1/state

echo "b" > /dev/rpmsg_pru30

*blue LED not behaving as expected *

Hello Le Son,

I am sorry for the delayed response. I will get a more detailed reply to you soon.

Regards,

Nick

Hello Le Son,

I suspect that the issue is related to the fact that button_led_0 and button_led_1 use PRU INTC event 16 (Lab 4), and PRU_RPMsg_LED0 also uses PRU INTC event 16 (Lab 6). The Lab 6 code relies on RemoteProc to initialize the INTC, while the Lab 4 code uses manual register writes to setup the INTC (though it also includes the resource_table information to allow RemoteProc to initialize the INTC). See the flow of my test process below. Note that button_led_0 works regardless of if another firmware was already run, but PRU_RPMsg_LED0 stops working after we load button_led_0.

remoteproc1: load PRU_Halt > start > stop > load PRU_RPMsg_LED0 > start > test works > stop > start > test works > stop > 
remoteproc2: >

remoteproc1: load button_led_0 > start > test works > stop > load PRU_RPMsg_LED0 > start > test now fails > stop > load button_led_0 > 
remoteproc2: load button_led_1 > start > test works > stop > 

remoteproc1: start > test works > stop
remoteproc2: start > test works > stop

I am not sure if RemoteProc was designed to load more than one firmware into a particular core. I am checking on that.

Regards,

Nick

Hello Le Son,

Still looking at RemoteProc behavior. I now suspect the issue is somewhere in RemoteProc, rather than in the INTC settings.

Lab 4 worked regardless of whether Lab 6 was loaded before it. That is because the Lab 4 firmware manually sets up INTC. If I comment out the Lab 4 manual INTC setup, then the INTC is only setup by RemoteProc based on the Lab 4 resource table. In that case, Both Lab 4 and Lab 6 work when they are the first firmware to get loaded into the PRUs. However, if I comment out the manual INTC setup, then neither lab will work properly if you run the other lab before it.

Regards,

Nick