This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
SMP Scheduler Behavior during startup
- From: Michael Jones <mjones at linear dot com>
- To: ecos discuss <ecos-discuss at sourceware dot org>
- Date: Thu, 19 Sep 2013 21:20:30 -0600
- Subject: SMP Scheduler Behavior during startup
- Authentication-results: sourceware.org; auth=none
I am debugging SMP startup for a new Cortex A9 HAL and have a few questions about startup behavior.
In the docs and in the code a lock is taken by secondary CPUs before calling cpu_start():
externC void cyg_kernel_smp_startup()
{
CYG_INSTRUMENT_SMP( CPU_START, CYG_KERNEL_CPU_THIS(), 0 );
Cyg_Scheduler::lock();
Cyg_Scheduler::start_cpu();
}
start_cpu() will setup the software interrupt.
The first question is which CPU and in what routine is the scheduler unlocked the first time?
The second question is which CPU starts the first thread?
Now, the reason I am asking is I am having a specific startup problem. The symptoms are:
- CPU 1 is started and results in a spinlock via Cyg_Scheduler::lock()
- CPU 0 is started
- The application starts two threads and the first thread runs on CPU 0
- The application thread calls cyg_mutex_lock on CPU 0
- cyg_mutex_lock calls spin on the spinlock and goes into an infinite loop
The spinlock variable has a 1, indicating that CPU 1 is holding the lock. I assume, but don't know, that the scheduler lock in cyg_kernel_smp_startup() is holding the lock, and something is not getting the scheduler unlocked. However, it is possible it is somewhere else in the code. I don't have a JTAG that works on both cores, so I can only debug on core 0 for now.
Some things that hopefully will help:
1) Single core without SMP runs fine, the UART works, etc. So nothing major wrong with the code.
2) By adding instrumentation code, I have proven that the CPU 1 startup works, and that cyb_kernel_smp_startup () is called. I write to memory I can see from CPU 0 and JTAG.
3) Interrupts for the real time clock and UART are only issued to CPU 0.
4) The code that setups the software ISR may not be correct. It is possible that interrupts are not delivered, and I am assuming I will get farther through the code and the unlock does not depend on the software interrupt. If the unlock depends on the interrupt, I would like to know how, and then I can spend some time getting the software interrupt working.
Regards
Mike
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss