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

[RTEMS trac]

#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 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).

 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.

 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.
 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.

 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.

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