03-06-2019 11:58 PM
zynq xc7z100 & SDK 2017.4.
I'm running AMP, baremetal on both cores.I'm using -Os on both cores. When both cores's .text locates in OCM, core0 runs to no where.
Here are the ld file of two project:
1. Anything incorrect with my ld script file?
when it runs to main, it looks as above, core0's calling stack is weird at 0xce3fe71c. I resume core0 and it runs to a state like below:
2. what's the problem?
ps. If I only launch core0 on the system debugger , it runs correct as below. If I move core1's .text to ddr, both cores also run normally.
03-11-2019 12:30 PM
I see 2 things.
First you cannot use the upper 256 bytes on the OCM (0xFFFFFE00 -> 0xFFFFFFFF) as it's used by the ROM start-up code.
Second, the code of both cores land in the same memory.. You have to split the OCM - one part for core #0 and the other for core #1.
03-11-2019 10:58 PM
Thank you @ericv ,
I already fix the size of upper address of OCM according to your first mention.
However, I don't see any overlap of my code memory.
Here's the script.ld of core0 :
Here's the script.ld of core1:
you mention that my code of both cores load in the same memory, I wonder how you see it ?? According to the two ld files above, the text of core0 locates in ps_ram_0 which is from 0x0 to 0x1EFFF. while text of core1 locates in ps_ram_1 which from 0x1F000 to 0x2FFFF. That makes the code of two cores land in two separate without overlapping memory segments. So I don't know why you think my code of two cores land in the same memory??
What's more, all other system sections are located in different segments in ddr, to be specific, core0 in ps_ddr_0 which is from 0x100000 to 0x64FFFFF and core1 in ps_ddr_1 which is from 0x6500000 to 0xC8FFFFF.
Onlyl 0xFFFF0000 to 0xFFFFFE00 in OCM and all upper area from 0xC900000 in DDR are used as share memories between two cores.
Am I misunderstood something??
03-13-2019 11:42 PM
Here's something more.
When I debug both cores on jtag, I select to download both cores' elf in debug configurations, after the cores launch in debug perspective, I see core0's code in the disassembly window, the assemble code is not like what it should be like as in core0's elf file. The normal assemble code is somehow replace to "andeq r0, r0, r0".
However, If I select only to download core0 in the debug configuration, and after both cores launch in debug perspective, I right click on the core1 and choose symbol files, then load core1's elf. This time, both cores work fine.
So it looks like core0's elf is somehow corrupted when core1 boot up. Will system debugger call FSBL to boot up both cores?
I'm not sure whether it has something to do with the boot up process in jtag mode.
03-15-2019 05:37 PM
03-18-2019 02:54 AM
Thank you @ericv ,
The .elf file itself already offers all the section informations. But I don't feel like it's a compile and linking problem . Since launching core0 only in system debugger works fine.
And like I metioned in my last post, if I load two cores' elf separately. Two cores working fine. So I feel it has something to do with the launching process of system debugger. Somehow it crashes core0's memory.
I did another test today. In my old ld file. core0's .text locates in ps7_ddr_0 segment which from 0x0 to 0x1EFFF while core1's .text locates in ps7_ddr_1 which from 0x1F000 to 0x2FFFF.
I did a little switch. I change ps7_ddr_0 to 0x1F000 to 0x2FFFF while ps7_ddr_1 to 0x0 to 0x1EFFF. Then both cores work well.
Feel like core0's text can't reside in memory base at 0x0.
So , is there any restriction in using 0x0 by core0 ?