From: Michael Jones <mjones@linear.com>
To: "Lambrecht Jürgen" <J.Lambrecht@TELEVIC.com>
Cc: ecos discuss <ecos-discuss@sourceware.org>
Subject: Re: [ECOS] Scheduler startup question
Date: Thu, 27 Feb 2014 16:40:00 -0000 [thread overview]
Message-ID: <DD2DBB97-4736-487F-AF3F-FFDF71677DAA@linear.com> (raw)
In-Reply-To: <jbx041itlgmp5ctby5fmojvm.1393483201068@email.android.com>
By tracing through a Cortex M application that works, I found that when the first thread is run, there is a loop at the bottom of the thread entry call that calls unlock until sched_lock is 0. Every thread entry does this.
This seems a bit dangerous to me, as the unlocking occurs anytime a new thread is created. I have to assume that the thread could not be entered when in a critical section between scheduler locks.
I'll look into that behavior and see if it is related to my BSD assertion.
On Feb 26, 2014, at 11:40 PM, Lambrecht Jürgen <J.Lambrecht@TELEVIC.com> wrote:
> As far as I know the scheduler is started after cyg_user_start(), used by your application to initialize everything. Do you use cyg_user_start?
>
>
> Verzonden vanaf Samsung Mobile
>
>
>
> -------- Oorspronkelijk bericht --------
> Van: Michael Jones <mjones@linear.com>
> Datum:
> Aan: ecos discuss <ecos-discuss@sourceware.org>
> Onderwerp: [ECOS] Scheduler startup question
>
>
> I have a question about proper scheduler locking startup behavior.
>
> The context is I am cleaning up my iMX6 HAL and attempting to make things work without a couple of kernel hacks I added to make it work.
>
> The question has to do with sched_lock. By default this has a value of 1, so during startup the scheduler is locked.
>
> When there is an interrupt, sched_lock is incremented in Vectors.S, and decremented in interrupt_end.
>
> However, I am getting an assert in sync.h which is part of the BSD stack. The assert is because it expects the lock to be zero.
>
> The question is, during the startup process, how does the lock get set to zero after initialization? Is it supposed to stay 1 while hardware is initialized and through all the constructors, etc? Is it cleared by the scheduler somehow? Is the HAL supposed to zero it at some point during startup?
>
> My HAL is part of the ARM hal, so if this is device specific, it is the ARM HAL I am working with.
>
> 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
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2014-02-27 16:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 6:40 Lambrecht Jürgen
2014-02-27 16:40 ` Michael Jones [this message]
2014-03-02 20:19 ` Michael Jones
2014-03-04 15:37 ` christophe
2014-03-04 15:58 ` Michael Jones
2014-03-04 16:17 ` christophe
2014-03-04 16:51 ` Michael Jones
2014-03-04 17:09 ` Michael Jones
-- strict thread matches above, loose matches on Subject: below --
2014-02-27 5:06 Michael Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DD2DBB97-4736-487F-AF3F-FFDF71677DAA@linear.com \
--to=mjones@linear.com \
--cc=J.Lambrecht@TELEVIC.com \
--cc=ecos-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).