[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:12 sebastian.huber]:
 > Replying to [comment:11 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.
 >
 > From the documentation:
 >
 > {{{
 >   /**
 >    * @brief Starts a processor specified by its index.
 >    *
 >    * This function is invoked on the boot processor during system
 >    * initialization.
 >    *
 >    * This function will be called after _CPU_SMP_Initialize().
 >    *
 >    * @param[in] cpu_index The processor index.
 >    *
 >    * @retval true Successful operation.
 >    * @retval false Unable to start this processor.
 >    */
 >   bool _CPU_SMP_Start_processor( uint32_t cpu_index );
 > }}}

 Ah thanks. I had not checked and assumed this was the cpu starting. This
 make sense.

 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.

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