FW: zc706 bsp does not work with maximum processors as 2

[Chris Johns]

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