David, Yes, for CE, you should actually change it in file Processor_dsplink_linkcfg_OS.c (that's the corresponding OS-specific dynamic configuration file in Codec Engine). This configuration will override the default DSPLink configuration in the cetools directory. I just mentioned basic changes in DSPLink, but a CE user will need to change the Codec Engine configuration.
The method you have mentioned, to check for an existing signal handler sounds useful. We'll check it out. Regards, Mugdha -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:17 PM To: Kamoolkar, Mugdha Cc: [email protected] Subject: RE: CERuntime_init/exit + threads Mugdha, Thanks for the info... do I need to edit any code in the IPC also? I think a better policy would be to check the signalhandler_t value that is returned from setting the handler against SIG_DFL and either emit a warning or not install a handler at all. DAVID A. KONDRAD Software Design Engineer On-Q/Legrand Telephone (800) 321-2343 x311 www.onqlegrand.com "Kamoolkar, Mugdha" <[EMAIL PROTECTED]> To "[EMAIL PROTECTED]" 07/25/2008 03:02 <[EMAIL PROTECTED]>, PM "[EMAIL PROTECTED] vincidsp.com" <[EMAIL PROTECTED] vincidsp.com> cc Subject RE: CERuntime_init/exit + threads 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
