public inbox for
 help / color / mirror / Atom feed
* [ECOS] SMP Scheduler Behavior during startup
@ 2013-09-20  3:20 Michael Jones
  0 siblings, 0 replies; only message in thread
From: Michael Jones @ 2013-09-20  3:20 UTC (permalink / raw)
  To: ecos discuss

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

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.


Before posting, please read the FAQ:
and search the list archive:

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-09-20  3:20 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-20  3:20 [ECOS] SMP Scheduler Behavior during startup Michael Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).