[RTEMS Project] #2343: [Patch] Fix Zynq SMP boot

RTEMS trac trac at rtems.org
Tue May 12 23:04:07 UTC 2015


#2343: [Patch] Fix Zynq SMP boot
----------------------------------------+---------------------
 Reporter:  jbrandmeyer                 |       Owner:
     Type:  defect                      |      Status:  new
 Priority:  high                        |   Milestone:  4.11.1
Component:  SMP                         |     Version:  4.10
 Severity:  normal                      |  Resolution:
 Keywords:  zynq, xilinx_zynq_zedboard  |
----------------------------------------+---------------------

Comment (by chrisj):

 Replying to [comment:14 jbrandmeyer]:
 > Replying to [comment:13 chrisj]:
 > > I think checking for '_start' means a bootloader that kicks the second
 CPU will fail as it will set a different value. I think the reset value is
 0 so would it be better to check for that and and then set _start ? I am
 not sure if it will make any difference but it might be cleaner.
 >
 > The reset value is not zero.  It is an address that points the ROM
 bootloader back to itself, so that if it gets an event before the address
 has been updated then it will just resume wfe again.  Worse, the exact
 value at the kick address is not guaranteed (see below).
 >

 What about kicking the core if the address is inside the BootROM address
 space ?

 > I also reviewed the FSBL support code you posted above and I have to say
 that it doesn't make much sense to me.  The wfe loop that your code
 injects is the same as the loop that the ROM booloader is already running.
 Why would you inject a second one?  The code would work just fine if you
 simply kicked off the second processor directly into RTEMS.

 The processor is brought into the bootloader when instructed to and waits.
 It can support POST testing before running RTEMS.

 >
 > Apparently there is no rigorous way to check if RTEMS has already been
 kicked off in the presence of a FSBL that can alter anything it pleases.

 I thought RTEMS waited for both cores to be present before finally
 finishing the initialisation so if RTEMS does not touch any specific
 resources it should be ok.

 > However, at this stage in the boot the OCM is "owned" by RTEMS, and I
 think that it can safely make the write to the kick-off address
 unconditionally.

 The OCM needs to have the first 3 64K blocks at the lower address range
 and the last one at the upper address range. The FSBL asm code assumes
 this with the various stacks set to the higher address range. This means
 you cannot change the OCM settings until RTEMS has moved the stacks,
 vector table and MMU table to the DDR memory.

 Note, bit 4 of the OCM config register is set to 1 by the BootROM and it
 must remain set. The BootROM sets the OCM cfg register to 0x18.

 >
 > For reference, the ROM bootloader is executing (gdb disassembly report):
 >
 >    0xffffff20:    dsb    sy
 >    0xffffff24:    wfe
 >    0xffffff28:    b    0xffffff20
 >    0xffffff2c:    dsb    sy
 >    0xffffff30:    wfe
 > => 0xffffff34:    mvn    r0, #15
 >    0xffffff38:    ldr    lr, [r0]
 >    0xffffff3c:    cmn    lr, #212    ; 0xd4
 >    0xffffff40:    beq    0xffffff2c
 >    0xffffff44:    mcr    15, 0, r0, cr7, cr5, {0}
 >    0xffffff48:    mcr    15, 0, r0, cr7, cr5, {6}
 >    0xffffff4c:    mcr    15, 0, r0, cr8, cr7, {0}
 >    0xffffff50:    mov    r4, #0
 >    0xffffff54:    mcr    15, 0, r4, cr1, cr0, {0}
 >    0xffffff58:    bx    lr
 >
 >    0xfffffff0 contains value 0xffffff2c
 >
 > However, Xilinx does not guarantee that the kick address points exactly
 to 0xffff ff2c - that is not part of their API.  In principle they could
 change it with a silicon revision or something.

 Yes and I suppose we would have to manage that when the time comes using
 version numbers.

--
Ticket URL: <http://devel.rtems.org/ticket/2343#comment:15>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list