[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 chrisj):

 Replying to [comment:10 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.

 I understand the sequence and all I am saying is the logic seems wrong. If
 the cpu is 0, ie ...

 {{{
  if ( cpu_index == 0 ) {
 }}}

 ... then starting cpu1 makes sense. Having cpu1 start itself does not make
 sense to me. Maybe I am missing something.

 FYI my boot loader and uboot (not the I have looked at the Zynq specific
 parts) do this before entering RTEMS. I had discussed this with Sebastian
 a while ago.

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

 Sure. I like the idea of RTEMS doing this. I avoids configuration issues
 in the bootloader ending up with a locked system.

 >
 > With regards to the MMU change, the user who overrides the weak symbol
 is already responsible for correctness of the entire memory map.

 There is a define with values that defines the base memory map and it is
 used by the weak symbol handlers.

 > IMO, announcing the change on the mailing list is easier to manage than
 splitting the MMU initialization into two stages.

 I do not agree. A post to a devel list is not a suitable way to resolve
 the issue and I would rather something better be found.

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

 Excellent.

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

 I use a customised FSBL to so I can boot RTEMS from a JFFS2 file system. I
 do not depend on Xilinx code or their SDK and I am happy working this way.
 My hope longer term is have umon be a better licensed replacement to the
 FSBL.

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