RTEMS only executes no task and only finds one core imx7

Stefan Akatyschew stefan.aka at posteo.de
Tue Mar 9 19:11:52 UTC 2021


Hi Gedare,
thanks a lot for your answer!
> Hi Stefan,
> 
> On Sun, Feb 28, 2021 at 8:04 AM Stefan Akatyschew
> <stefan.aka at posteo.de> wrote:
>> 
>> Hello together,
>> after I could successfully fiddle around with some tasks on a single
>> core, I tried to get some basic SMP application running.
>> I use as before trace32 to load the program and added parts from the
>> lauterbach iMX7-sabre SMP startup script. With that I at get both cores
>> running. And also my RTEMS 5 compiler tells me, that RTEMS_SMP is defined.
>> 
> And it should work on iMX7
> https://docs.rtems.org/branches/master/cpu-supplement/arm.html#symmetric-multiprocessing
> 
> I don't personally have experience with that, so I can only give some
> general advice.

Any advice is appreciated and helps :)
I tried it now also with the rtems 6 master and I have the same problem
with it. I also checked as suggested the bspsmp.c files a bit, also
looked for other maybe significant differences in the dtf, but couldn't
spot any. But I'm also not really familiar with it.

>> For my application code, I oriented myself on the "smp01" example. https://git.rtems.org/rtems/tree/testsuites/smptests/smp01
>> Unfortunately I see that core 0 is stuck in the "smpmulticastaction.c"
>> in some loading functions, I can't really wrap my head around? While
> Which function? can you backtrace?

That are actually a few, it circles around those:
rtems/score/cpuimpl.h:101 Per_CPU_Control
*_ARM_Get_current_per_CPU_control( void )
rtems/score/cpustdatomic.h:250 long _CPU_atomic_Load_ulong( const
CPU_atomic_Ulong *obj, CPU_atomic_Order order )
rtems/score/src/smpmulticastaction.c:88 _Per_CPU_Try_perform_jobs(
Per_CPU_Control *cpu_self )
rtems/cpukit/score/src/smpmulticastaction.c:110 void
_Per_CPU_Wait_for_job(const Per_CPU_Control *cpu, const Per_CPU_Job *job)
rtems/score/cpu.h:252 void _ARM_Data_synchronization_barrier( void )
rtems/score/cpu.h:492 void _ARM_Send_event( void )
(attached rtems5-smp.png)
I can also see that none of my threads is actually running, only
_CPU_Thread_Idle_body (attached picture rtems5-smp-threads.png)


>> core 1 is stuck at an IRQ intialisation routine (in irq/irq-gic.c) for
> ditto?

I can't really debug the second core somehow. Though Trace32 is supposed
to step through core 0 and 1 simultaniously (in SMP), it does only work
on core 0 for me. Trying to do that on core 1 results in bus error for me...
All I see is it being stuck at : irq/irq-gic.c:157
BSP_START_TEXT_SECTION void arm_gic_irq_initialize_secondary_cpu(void)

>> the second core.
>> I tried fiddeling around with the configuration and different taks, but
>> get always the same response. I've gone through the user manual and the
>> API guide, but couldn't find any problems.
>> The application as is works fine on a single core, if I set the
>> CONFIGURE_MAXIMUM_PROCESSORS to 1.
>> 
>> Any ideas what I'm doing wrong? I attached my two source files and the
>> practice Script.
>> 
> 
> Unfortunately, I don't think the SMP boot sequence is well-documented.
> You probably have to work your way through the code.
> bsps/arm/shared/start/arm-a9mpcore-smp.c
> 
> There is some doxygen that might help you too:
> https://docs.rtems.org/doxygen/branches/master/group__ScoreSMP.html
> 
> and you can check out the bspsmp.c files beneath bsps/ of some other
> implementations for some ideas.
> 
> We probably need a section related to SMP initialization added to
> https://docs.rtems.org/branches/master/bsp-howto/index.html
> 
> Maybe someone with more experience on this particular board or with
> arm/SMP will be able to suggest better insight.
> 
> -Gedare
> 
>> Thanks a lot for your help.
>> Kind regards,
>> Stefan_______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems5-smp-threads.png
Type: image/png
Size: 12014 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20210309/b903c86b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems5-smp.png
Type: image/png
Size: 157254 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20210309/b903c86b/attachment-0003.png>


More information about the users mailing list