-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpmsg_multi_services demo runs only once after reboot #56
Comments
Few questions from above logs:
|
Thank you for looking into that.
|
Not sure what could be the issue here. I will have to setup and run demo. Meanwhile few things to try:
|
Sorry I mean /sys/bus/rpmsg/devices/ output ? |
interrupts before demoxilinx:/lib/firmware# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 46862 13611 9083 10219 GICv2 30 Level arch_timer
14: 0 0 0 0 GICv2 67 Level zynqmp-ipi
15: 0 0 0 0 GICv2 58 Level ffa60000.rtc
16: 0 0 0 0 GICv2 59 Level ffa60000.rtc
17: 0 0 0 0 GICv2 88 Level ams-irq
18: 0 0 0 0 GICv2 155 Level axi-pmon, axi-pmon
19: 0 0 0 0 GICv2 175 Level arm-pmu
20: 0 0 0 0 GICv2 176 Level arm-pmu
21: 0 0 0 0 GICv2 177 Level arm-pmu
22: 0 0 0 0 GICv2 178 Level arm-pmu
23: 305 0 0 0 GICv2 54 Level xuartps
25: 0 0 0 0 GICv2 156 Level zynqmp-dma
26: 0 0 0 0 GICv2 157 Level zynqmp-dma
27: 0 0 0 0 GICv2 158 Level zynqmp-dma
28: 0 0 0 0 GICv2 159 Level zynqmp-dma
29: 0 0 0 0 GICv2 160 Level zynqmp-dma
30: 0 0 0 0 GICv2 161 Level zynqmp-dma
31: 0 0 0 0 GICv2 162 Level zynqmp-dma
32: 0 0 0 0 GICv2 163 Level zynqmp-dma
33: 0 0 0 0 GICv2 109 Level zynqmp-dma
34: 0 0 0 0 GICv2 110 Level zynqmp-dma
35: 0 0 0 0 GICv2 111 Level zynqmp-dma
36: 0 0 0 0 GICv2 112 Level zynqmp-dma
37: 0 0 0 0 GICv2 113 Level zynqmp-dma
38: 0 0 0 0 GICv2 114 Level zynqmp-dma
39: 0 0 0 0 GICv2 115 Level zynqmp-dma
40: 0 0 0 0 GICv2 116 Level zynqmp-dma
41: 0 0 0 0 GICv2 154 Level fd4c0000.dma-controller
42: 0 0 0 0 GICv2 151 Level fd4a0000.display
43: 1426 0 0 0 GICv2 52 Level ff050000.spi
44: 31138 0 0 0 GICv2 47 Level ff0f0000.spi
45: 1991 0 0 0 GICv2 89 Level eth1, eth1
46: 0 0 0 0 GICv2 91 Level eth0, eth0
47: 0 0 0 0 GICv2 57 Level axi-pmon, axi-pmon
48: 2845 0 0 0 GICv2 50 Level cdns-i2c
50: 0 0 0 0 GICv2 84 Edge ff150000.watchdog
51: 13677 0 0 0 GICv2 97 Level xhci-hcd:usb1
52: 93 0 0 0 GICv2 102 Level xhci-hcd:usb3
53: 0 0 0 0 zynq-gpio 12 Edge fwuen
IPI0: 236 335 357 222 Rescheduling interrupts
IPI1: 4062 10788 16574 5163 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0 after first run: xilinx:/lib/firmware# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 58602 17355 14249 13498 GICv2 30 Level arch_timer
14: 104 0 0 0 GICv2 67 Level zynqmp-ipi after second run: xilinx:/lib/firmware# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 65500 18714 17040 14987 GICv2 30 Level arch_timer
14: 104 0 0 0 GICv2 67 Level zynqmp-ipi after third run: xilinx:/lib/firmware# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 86821 20055 19411 16651 GICv2 30 Level arch_timer
14: 107 0 0 0 GICv2 67 Level zynqmp-ipi and the rpmsg devices: xilinx:/lib/firmware# ls /sys/bus/rpmsg/devices/
virtio0.rpmsg-client-sample.-1.1024 virtio0.rpmsg-tty.-1.1025 virtio0.rpmsg_ns.53.53
virtio0.rpmsg-raw.-1.1026 virtio0.rpmsg_ctrl.0.0 For the stack sizes I use: #define APP_TASK_STACK_SIZE (2048)
#define MAX_TTY_EPT 2
#define MAX_RAW_EPT 2
/* Add 512 extra bytes for the TTY task stack for the "tx_buff" buffer. */
#define APP_TTY_TASK_STACK_SIZE (2048)
#define APP_RAW_TASK_STACK_SIZE (2048) and CONFIG_MAIN_STACK_SIZE=2028
CONFIG_HEAP_MEM_POOL_SIZE=2048 |
I can see devices are created and interrupt count is also increasing from 104 to 107 for third run. For second run I don't see interrupt count is incremented. So, even name service announcement failed for second run, but it happened for third run. I will have to attempt to reproduce this issue on my end to debug further. I am wondering if name service announcement can happen then why zephyr should hang after that? No obvious reason I can think of. |
Are you trying rpmsg-tty demo ? after second start / third start ? |
Sorry I mean after third start? Because second start devices aren't even created. |
The output for the third run with the tty-demo:
gives the bash error:
even though:
and dmesg:
|
From #52 I looked at zephyr overlay.
Could you remove above ? That wasn't introduced in original overlay for qemu_cortex_r5. I am not sure if it will resolve the issue or not, but worth the try. In above logs, I see that zephyr stopped responding completely. May be zephyr crashed because TCM is assigned instead of OCM. |
Ah! now I remember that later it was introduced as sram node: https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/zephyr/rpmsg_multi_services/boards/zynqmp_r5_override.dtsi However, this was tested on zephyr 3.5.0. Looks like I will have to replicate this setup and test it with zephyr 3.6. I will get back once I do that. |
I noticed something else too: So Linux device-tree configures cluster in split mode:
This will automatically configure TCM in split mode too. i.e. 128K TCM per core. However, Zephyr is trying to use 256K TCM:
I think this is not correct. Zephyr should use only 128K TCM.
It's possible that zephyr code doesn't fit completely in TCM. You might have to change linker script and put some of the text section in |
So far zephyr overlay is tested only for lockstep mode. Split mode work is still in progress. |
In the KV260 Board description from Zephyr they write:
But for me the assignment and effect of the
When I load the firmware via the xlnx_r5_remoteproc driver I understand that it is placed at the address Regarding the firmware size I thing for this demo we do not have a size problem, since:
|
0x3ed0_0000 address isn't used for zephyr firmware. It's only used for XLNX baremetal firmware as of now. Only 128K should be used per core for split mode. I don't know what will be the effect if r5 core0 uses r5 core1's TCM in split mode. I tested zephyr firmware (zephyr 3.6) on zcu102 qemu board and repeat start stop is working there. However, It's too soon to concluded anything as it's not real hardware. |
I tested with R5 cluster configured in lockstep mode on qemu. Still need to see behavior in split mode. Meanwhile for experiment change cluster mode to lockstep mode in linux and see if it changes anything. I don't have any solution for this issue as of now, I have to go for trial and error method here, until I have setup. |
If I uncomment the two following threads in the demo and only run the int main(void)
{
printk("Starting application threads!\n");
k_thread_create(&thread_mng_data, thread_mng_stack, APP_TASK_STACK_SIZE,
(k_thread_entry_t)rpmsg_mng_task,
NULL, NULL, NULL, K_PRIO_COOP(8), 0, K_NO_WAIT);
// k_thread_create(&thread_rp__client_data, thread_rp__client_stack, APP_TASK_STACK_SIZE,
// (k_thread_entry_t)app_rpmsg_client_sample,
// NULL, NULL, NULL, K_PRIO_COOP(7), 0, K_NO_WAIT);
// k_thread_create(&thread_tty_data, thread_tty_stack, APP_TTY_TASK_STACK_SIZE,
// (k_thread_entry_t)app_rpmsg_tty,
// NULL, NULL, NULL, K_PRIO_COOP(7), 0, K_NO_WAIT);
k_thread_create(&thread_raw_data, thread_raw_stack, APP_TASK_STACK_SIZE * 2,
(k_thread_entry_t)app_rpmsg_raw,
NULL, NULL, NULL, K_PRIO_COOP(7), 0, K_NO_WAIT);
return 0;
} I get after pinging the
I do this directly after booting and I do not start the firmware twice (seems to be loaded twice from the UART log). |
After solving #52 now I run into the issue that the provided demo does not run for a second time.
Zephyr hangs on:
Loaded modules:
Steps to reproduce
Logs
dmesg output
UART log
Any help?
The text was updated successfully, but these errors were encountered: