David,
DSPLink installs a signal handler by default to cleanup its own resources. But
you can disable it by updating in the DSPLink dynamic configuration file
CFG_Linux.c. Set HANDLESIGNALS to FALSE.
FALSE, /* HANDLESIGNALS : Should signals be
handled for cleanup */
Recommended policy is exactly what you're doing ... i.e. writing your own
signal handler for cleanup. DSPLink only installs a signal handler to enable
early development when your application is not yet fully developed and may
frequently crash/require you to Ctrl C. At that point, you definitely wouldn't
have a signal handler written in your application. Once the application
stabilizes, you can (and should) write your own signal handlers and disable the
DSPLink signal handling.
Regards,
Mugdha
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 25, 2008 11:26 AM
To: [email protected]
Subject: CERuntime_init/exit + threads
Greetings,
We're experiencing some really weird things with CE 2.10.01 + threads...
I've checked that our threads are all opening their own CE handles and we don't
have mutual exclusion problems...
However, we can't seem to terminate the application smoothly...
I've installed a signal handler for SIGINT and we're shutting down our threads
before calling CERuntime_exit.
Questions:
1. Does CE install any signal handlers?
2. Does each thread require it's own call to CERuntime_init/exit pairs?
(Docs don't specify)
3. What is the recommended signal handling policy for CE enabled apps?
Regards,
David
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
www.onqlegrand.com
davinci-linux-ope
n-source-request@
linux.davincidsp. To
com [EMAIL PROTECTED]
Sent by: incidsp.com
davinci-linux-ope cc
n-source-bounces@
linux.davincidsp. Subject
com Davinci-linux-open-source Digest,
Vol 31, Issue 40
07/24/2008 01:00
PM
Please respond to
davinci-linux-ope
[EMAIL PROTECTED]
vincidsp.com
Send Davinci-linux-open-source mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of Davinci-linux-open-source digest..."
Today's Topics:
1. RE: YAFFS2 with checkpointing on DM355 (Phil Quiney)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jul 2008 16:44:10 +0100
From: "Phil Quiney" <[EMAIL PROTECTED]>
Subject: RE: YAFFS2 with checkpointing on DM355
To: "Jon Povey" <[EMAIL PROTECTED]>,
<[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
I discovered /proc/yaffs and that was telling me that my file system was yaffs
and not yaffs2.
It looks like YAFFS2 does not like the 16k erase block size of the MX27 NAND
FLASH module. I tried a kernel with the 'auto YAFFS switch' removed (it is
supposed to use the -t option to mount rather than 'guess' from the erase block
size) and it refused to mount as yaffs2. From what I can see
YAFFS2 needs 2k erase blocks and anything else forces YAFFS1.
So no checkpointing then ;-(
Regards
Phil Q
Phil Quiney, Senior Software Engineer
Trinity Convergence
Cambridge Business Park
Cowley Road
Cambridge CB4 0WZ, UK
T: +44(0)1223-435536
F: +44(0)1223-435560
www.trinityconvergence.com
-----Original Message-----
From:
[EMAIL PROTECTED]
davinci-linux-open-source-bounces+avincidsp.com
[mailto:[EMAIL PROTECTED]
On Behalf Of Jon Povey
Sent: 24 July 2008 15:53
To: [email protected]
Subject: RE: YAFFS2 with checkpointing on DM355
> -----Original Message-----
> From: Phil Quiney [mailto:[EMAIL PROTECTED]
> Sent: 24 July 2008 15:45
> To: Jon Povey; [email protected]
> Subject: RE: YAFFS2 with checkpointing on DM355
> I tried mounting the NAND partition with yaffs2 and it seems to take
> around 11-15 seconds to mount regardless of content.
> The MX27 core is an ARM926EJ-S running at 400MHz (199 BogoMIPS).
>
> When unmounting - it printed 'save exit: isCheckpointed 0' on the
> console - whatever that means.
Hmm, that looks like it's not creating a checkpoint, for whatever reason.
When I tried the recent YAFFS2 code it said isCheckpointed 1 on unmount (but
failed to mount again).
I have read that checkpointing can reduce several-second mount times down to
the order of a second.. When I was googling around at some point, I don't have
a source handy for that.
> Are there any YEFFS related settings you want me to change & try
> again?
The kernel config looked OK to me, I don't know enough about YAFFS2 to know why
it might not have been checkpointing properly, if that was the case.
For want of a better, and quicker, idea at the moment I am chopping down my
root fs as much as possible and will try shrinking the mtd partition too, and
see what that does for my boot times. If I can get it down to around 3s that
will be acceptable.. There are some gains to be had in optimising the startup
scripts too.
Commercial pressures are nudging me that way for an initial release:
later on I can take the time to fix YAFFS2 on DM355 and release a firmware
update.
--
Jon Povey, Design Engineer
[EMAIL PROTECTED] | +44(0)1280 825983
Racelogic is a limited company registered in England. Registered number
2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged.
If you have received this electronic mail transmission in error, please delete
it from your system without copying or forwarding it, and notify the sender of
the error by reply email so that the sender's address records can be corrected.
The views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
End of Davinci-linux-open-source Digest, Vol 31, Issue 40
*********************************************************
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
