RTEMS only executes no task and only finds one core imx7

[Stefan Akatyschew]

Hello together,

I think it is stuck in the _Per_CPU_Wait_for_job function in
kernel/rtems/cpukit/score/src/smpmulticastaction.c and I found the
comment in the case statement:
        /*
         * Calling this function with the current processor is intentional.
         * We have to perform our own jobs here in case inter-processor
         * interrupts are not working.
         */
I assume there still must be something wrong with the device tree file,
for those interrupts to fail? Is there any way to verify if that is the case?

Kind Regards,
Stefan

On Mar 9 2021, at 8:11 pm, Stefan Akatyschew <stefan.aka at posteo.de> wrote:

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