[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:8 chrisj]:
 > I am not sure about this change.
 >
 > I do not understand the logic in _CPU_SMP_Start_processor where the CPU
 index is checked for 1 (cpu1 ?) and if cpu1 has not started it is kicked.
 Why would you do this for cpu1 or is the index numbered from 1 ( so cpu0
 ?) ?
 >
 > The change on partial handles a full SMP initialization for example the
 SMP bit in the CP15 ACTLR register.

 Yes, the CPU's are numbered from zero.  The boot sequence is as follows:
 The Zynq ROM bootloader loads and executes a single file, itself a
 fragment of a proprietary-formatted boot image, typically the Xilinx First
 Stage Bootloader (FSBL).
 The FSBL performs low-level hardware and FPGA fabric initialization and
 also loads an arbitrary ELF file (in this case, an RTEMS application) and
 starts CPU0 at the ELF's entry point.  However, CPU1 sits waiting.
 So when RTEMS starts its initialization, it is already running on CPU0.
 And the only thing that it can possibly do with regards to SMP
 initialization is to start CPU1.

 As this BSP is specific to the Zynq, there can be only one more CPU.  The
 change follows the logic from the Altera Cyclone V BSP, which is a direct
 competitor to the Zynq with a nearly identical hard processor subsystem.

 With regards to the MMU change, the user who overrides the weak symbol is
 already responsible for correctness of the entire memory map.  IMO,
 announcing the change on the mailing list is easier to manage than
 splitting the MMU initialization into two stages.

 I have confirmed that simply marking the memory with the READ_WRITE
 permissions instead of as device memory is also sufficient to work around
 the cache problems.

 Yet another alternative to this patch would be to tell users that in order
 to boot RTEMS in SMP mode, that they need to customize the Xilinx FSBL in
 a certain way.  IMO, that is less satisfactory than doing The Right Thing
 with the default tools as provided by Xilinx.

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