It can be closed. The added documentation is very helpful.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921092
Title:
gdbstub debug of multi-cluster machines is undocumented and confusing
Status
qemu-system-arm -cpu cortex-m33 -machine mps2-an521 -nographic -m 16
-vga none -net none -chardev stdio,id=con,mux=on -serial chardev:con
-mon chardev=con,mode=readline -icount shift=7,align=off,sleep=off -rtc
clock=vm -device loader,file=/zephyr.elf -s -S -kernel
/zephyr.elf
i've included both .e
Thanks for the answer,
indeed the second cluster of the board has been halted when I was
starting gdb the "normal" way - not adding the second inferior. In my
own research I did not find out about these inferiors, so I was
wondering why "info threads" did only show one cpu. Maybe gdb could
inform
there was no bug, it was my fault. How do I delete this
** Changed in: qemu
Status: New => Invalid
** Summary changed:
- qemu-system-arm multi core debug not working
+ how do i delete this bug?
** Description changed:
- Working with Zephyr RTOS, running a multi core sample on mps2_an521
** Description changed:
Working with Zephyr RTOS, running a multi core sample on mps2_an521 works
fine. Both cpus start.
Trying to debug with options -s -S the second core fails to boot.
Posted with explanation also at:
https://github.com/zephyrproject-rtos/zephyr/issues/33635
+
+ only af
Public bug reported:
Working with Zephyr RTOS, running a multi core sample on mps2_an521 works fine.
Both cpus start.
Trying to debug with options -s -S the second core fails to boot.
Posted with explanation also at:
https://github.com/zephyrproject-rtos/zephyr/issues/33635
** Affects: qemu
