RTEMS only executes no task and only finds one core imx7
stefan.aka at posteo.de
Thu Mar 11 18:20:48 UTC 2021
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?
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
>> 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
> 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.
>> There is some doxygen that might help you too:
>> 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
>> Maybe someone with more experience on this particular board or with
>> arm/SMP will be able to suggest better insight.
>>> Thanks a lot for your help.
>>> Kind regards,
>>> users mailing list
>>> users at rtems.org
More information about the users