On 2020-04-02 18:45, Fernando Domínguez Pousa wrote:
Hi again,
Finally I could continue my tests on zc706 and the second processor start.
I could add two breakpoints one at _CPU_SMP_Start_processor (0x0041e7b0) and
other at _Per_CPU_State_wait_for_non_initial_state (0x0041e7d4) at the end of
the function _CPU_SMP_Start_processor. Execution stops and continues in both
breakpoints, but I still need to need to start the second processor from xsdb.
I attach you a capture of the objdump done at the end of the mail.
The way the process is started is by a write to an address
(0xfffffff0UL). The second core is parked in code in the ROM monitor
that is in zynq and when kicked it jumps to the address held in the
special location. At power up the address points to a ROM loop that just
loops and power downs. I wonder if xsdb is doing something with the core
that is effecting what happens?
Yes I believe so. I tested the m2003 version.
Can you share me the compilation flags you use for your tests executables?
I use the ones RTEMS uses to build the BSP with some changes in the
warning flags. You need to do this to maintain the ABI ...
https://docs.rtems.org/branches/master/user/exe/executables.html#machine-flags-and-abi
And sorry for this answer, but where can I find the m2003 version? Is it a git
tag, branch.. ? I don't see anything similar on GitHub repos.
Please try the m2004 snapshot. You should have received an email about it.
I wonder if xsdb is doing something. Are you able to set a break point
in the code I provided to the link to in zynq_start_bspsmp.c
Maybe the JTAG hardware could cause this...
It is not the hardware rather the xsdb software. You may need to tell it
to use the second core and what it needs to do. I know with OpenOCD you
need to tell it you have both cores running.
Chris
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
