Hello,
I'd like to know if there is any example of using remoteproc with ls1021a cpu that I can use as reference?
I'm currently trying to "port" the Xilinx echo_test app in document UG1186 to an twr-ls1021a board. I basically modifiy the code that has been used for the zynq_remoteproc driver (linux-xlnx/zynq_remoteproc.c at master · Xilinx/linux-xlnx · GitHub ).
After several modifications, I'm at the point where the firmware is about to be copied into the memory location where the secondary core expects it to be. However, I don't understand what is done with mem_pools, virtual addr, etc within the "zynq_remoteproc_probe" method and I dont know what I'm supposed to write into my device tree file.
I'd appreciate any help,
Thanks ,
Yaset
UPDATE:
Some parts of the driver seem to work. It loads and create the sysfs files where i can set the firmware and the state. After setting the state to "start" , i can see the start function of the driver doing the procedure to boot the cpu1, that is:
1- set Boot Release Register (DCFG_CCSR_BRR) to release cpu 1
2- set start address where the firmware should be (0xa0000000 in my case) into register (scratch1)
3- execute the "sev" instruction.
Note that i've successfully tested this procedure from u-boot. The difference is that now, within the driver, i use virtual addresses for accessing those registers. I get the virtual addresses from the ioremap function.
So, cpu1 is supposed to be executing the firmware. The firmware just writes a predefined value into another shared register (scratch2). Then from my driver i read at the address assigned to this register (again i use ioremap to get the virtual address), but the expected value isn't there.
I should tell that i'm booting the kernel with only cpu0. Could it affect my driver?
Is there a way to know whether the cpu 1 is running?
Have a great day,
Pavel Chubakov
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thanks for your answer.
The instructions in those files are already implemented in the driver i'm using as reference.
My problem is specific to the way i start the second core. As I said above, I'm replaying the same procedure that I do before from u-boot.
Now, the problem is that the system reboots itself just after I set the Boot Release Register.
Could you explain this behavior?
UPDATE:
It is working now!
In fact, as soon as i set the BRR it starts so i set the start address first.
Also, contrarily to what i do from u-boot, the "SEV" instruction is not required!
It seems that after the kernel has load, cpu1 is not in the same state that at u-boot.
Is this the expected behavior?