Zybo z7-20 boot problem: PC jumps to 0 during OKToRun

[Kyle Hagen]

Hello everyone,

Im having issues getting one of our Zybos to boot. Ive tried building and running the Hello World program using Xilinx design tools 2020.1, 2019.2 and 2018.2. 

Something seems to go wrong in the OKToRun label, specifically at the line in boot.S commented: "/* read diagnostic register */" , the program counter jumps to 0. 

Jump to 0 in boot.S

#ifdef CONFIG_ARM_ERRATA_743622
    teq     r5, #0x00200000                 /* only present in r2p* */
    mrceq   p15, 0, r10, c15, c0, 1         /* read diagnostic register */ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    orreq   r10, r10, #1 << 6               /* set bit #6 */
    mcreq   p15, 0, r10, c15, c0, 1         /* write diagnostic register */
#endif

Jump to 0 in disassembly 

          OKToRun:
0010017c:   mrc     p15, 0, r0, c0, c0
221       	and     r5, r0, #0x00f00000
00100180:   and     r5, r0, #15728640
...
232       #ifdef CONFIG_ARM_ERRATA_743622
00100198:   mcrle   p15, 0, r10, c15, c0, 1
233       	teq     r5, #0x00200000                 /* only present in r2p* */
0010019c:   teq     r5, #2097152
234       	mrceq   p15, 0, r10, c15, c0, 1         /* read diagnostic register */
001001a0:   .word 0xff1faf30										<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
235       	orreq   r10, r10, #1 << 6               /* set bit #6 */
001001a4:   orreq   r10, r10, #64
236       	mcreq   p15, 0, r10, c15, c0, 1         /* write diagnostic register */
237       #endif
238       
239       	/* set VBAR to the _vector_table address in linker script */
001001a8:   mcreq   p15, 0, r10, c15, c0, 1
...

 

Using 2018.2, this is what I'm doing and seeing: 

in Vivado: 
1) New project, selecting the installed Zybo z7-20 board, all other option default. 
2) Create Block Diagram. 
3) Add PS
4) Connect M_AXI_GP0_ACLK to FCLK_CLK0
5) Create HDL wrapper for the bd file, let Vivado manage this 
6) Generate bitstream 
7) Export hardware 
Launch SDK 

In SDK: 

1) Create new application project, standalone domain, core0, c language, Hello World example 
2) Builds no problem. 
3) Debug configuration - check "Stop at program entry" 
4) Start the debugger
5) Instruction stepping mode: 

00100000: b +292 ; addr=0x0010012c: _prestart
_prestart:
0010012c: mrc p15, 0, r1, c0, c0, 5
00100130: and r1, r1, #15
00100134: cmp r1, #0
00100138: beq +4 ; addr=0x00100144: CheckEFUSE
CheckEFUSE:
00100144: ldr r0, [pc, #+764]
00100148: ldr r1, [r0]
0010014c: ands r1, r1, #128
00100150: beq +36 ; addr=0x0010017c: OKToRun
OKToRun:
0010017c: mrc p15, 0, r0, c0, c0
00100180: and r5, r0, #15728640
00100184: and r6, r0, #15
225 #ifdef CONFIG_ARM_ERRATA_742230
00100188: orr r6, r6, r5, lsr #16
0010018c: cmp r6, #34
00100190: mrcle p15, 0, r10, c15, c0, 1
00100194: orrle r10, r10, #16
232 #ifdef CONFIG_ARM_ERRATA_743622
00100198: mcrle p15, 0, r10, c15, c0, 1
0010019c: teq r5, #2097152
001001a0: .word 0xff1faf30            <<<<<<<<<<<<<<<<<<<<<< Stepping into this causes the program counter to go to address 00000004
00000004: andeq r0, r0, r0
00000008: andeq r0, r0, r0
0000000c: andeq r0, r0, r0
00000010: andeq r0, r0, r0
etc...
0002fffc: andeq r0, r0, r0
0000000c: andeq r0, r0, r0
00000010: andeq r0, r0, r0
00000014: andeq r0, r0, r0
etc...

 

Can anyone help me understand why the PC is jumping to 0 and what might be wrong here? Any help is greatly appreciated. 

 

Thanks in advance,

Kyle 

 

 

 

[Kyle Hagen]

As an update, I got my hands on another z7-20 here and it's working as expected.

The only things I can come up with here is that
1) There's physical damage to the first one which jumps to zero or
2) The onchip flash memory is different and that's causing an issue?

Can anyone speak to the importance of the QSPI flash contents for a Zynq and what can be done to restore it to what it would have shipped with?

[xc6lx45]

Hi,

did you check the boot mode configuration section (QSPI vs SD)?

See https://reference.digilentinc.com/reference/programmable-logic/zybo-z7/reference-manual section 2

- Is the jumper set correctly?
- if QSPI, is there a valid FSBL in one board and not the other?

I wouldn't be surprised if there a default FSBL in the working board that tries multiple options until it finds the first bootable image. An easy way to check is to clear the flash of the working board. If it stops working, you've found the root cause (obviously it'll "break" the working board temporarily but building and flashing the default FSBL should be a routine job, takes a few mouse clicks, at least on other boards)

[Kyle Hagen]

Hello xc6lx45,

Thanks for your help.

To your question: I've tried with the jumper in all 3 positions, but typically we run it in SD. Actually, we have an SD card with our standalone app and a linux image which is booting and working correctly on our system (a stewart platform running inverse and forward kinematics). It's really quite wonderful the latency and performance we're getting from the Zynq.

However when I try and boot that SD card on this particular Zybo, nothing happens.

To recap: we have 3 Zybos in total: 2 function as expected when debugging or booting from the SD card, but this particular one is having some kind of issue.

 

Some new information:

Potentially corrupted RAM?

Last night at home using my hello_world build on Vivado 2018.2 and SDK, I was seeing that strange .word 0xff1faf30 command in the disassembly show up in different places over consecutive debugging sessions. Also the hex value was not always the same. In all cases, if the program counter ended up on that command, stepping over it resulted in the jump to address 00000004. The .word command typically appears in the OkToRun routine, but sometimes in the second #ifdef, sometimes after it.
This morning, when running from Vitis 2019 this is what I see:

          OKToRun:
00100158:   mrc     15, 0, r0, cr0, cr0, {0}
215       	and     r5, r0, #0x00f00000
0010015c:   and     r5, r0, #15728640       ; 0xf00000
216       	and     r6, r0, #0x0000000f
00100160:   and     r6, r0, #15
217       	orr     r6, r6, r5, lsr #20-4
00100164:           ; <UNDEFINED> instruction: 0xff866825
220               cmp     r6, #0x22                       /* only present up to r2p2 */
00100168:   cmp     r6, #34 ; 0x22
221               mrcle   p15, 0, r10, c15, c0, 1         /* read diagnostic register */
0010016c:   mrcle   15, 0, r10, cr15, cr0, {1}
222               orrle   r10, r10, #1 << 4               /* set bit #4 */
00100170:   orrle   r10, r10, #16
...
001001b8:   mcr     15, 0, r0, cr1, cr0, {0}
267       	mrs	r0, cpsr			/* get the current PSR */
001001bc:           ; <UNDEFINED> instruction: 0xff0f0000
268       	mvn	r1, #0x1f			/* set up the irq stack pointer */
001001c0:   mvn     r1, #31
269       	and	r2, r1, r0
001001c4:   and     r2, r1, r0
...

When I step through the healthy Zybo, it looks like the above but without the <UNDEFINED> instructions.

 

Maybe we're just looking at some ESD damage to the board or something? The variability here doesn't strike me as a Zynq that's just configured wrong... The Zybo has been passed around the office and worked on by a couple different people at this point.