UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
355 Views
Registered: ‎01-31-2018

Multiple processors in a DDR-less system

Hello,

 

My team and I are working on a DDR-less configuration that will run on top of standalone. We have started with this example:

http://www.wiki.xilinx.com/Zynq-7000+AP+SoC+Boot+-+Booting+and+Running+Without+External+Memory+Tech+Tip

 

We needed to implement a non-XIP bootloader for the FSBL in order to access >16MB of QSPI Flash. This has been achieved, and we switch back into XIP mode before booting into the CPU0 application. For this reason, we have not been using the L2 cache preload / lockdown, which this tip suggests. 

 

App0 will start App1 with the CPU1STARTADR taken from the example.

 

App1 is compiled with USE_AMP=1, and it calls the standard boot code from standalone 6.5, boot.S.

 

The CPU crashes as soon as the system tries to enable the MMU and caches. 

 

	/* Enable mmu, icahce and dcache */
	ldr	r0,=CRValMmuCac
	mcr	p15,0,r0,c1,c0,0		/* Enable cache and MMU */
	dsb					/* dsb	allow the MMU to start up */
	isb					/* isb	flush prefetch buffer */

I suspect this could be an issue with either the MMU's Translation Table, or something going awry with the L2 cache. Is there something inherently wrong with this type of design? Are there other things that must be done in order to start the second MMU?

 

We thought everything was working a while back, but realized the MMU wasn't working when an unaligned memcpy() caused a DataAbort.

 

Any help or suggestions would be greatly appreciated!

0 Kudos
1 Reply
Contributor
Contributor
305 Views
Registered: ‎01-31-2018

Re: Multiple processors in a DDR-less system

To respond with how this was finally solved:

 

Our app didn't correctly use the boot code from boot.S. This would have worked successfully, however:

Our FSBL didn't copy the second processor's data into OCM. So even when we got the linker script loaded correctly, it was pointing to invalid memory.

 

After this, modifications to the coprocessor registers for SCTLR / TTBR0/1 and DACR work successfully and we're up and running!