> Also, since I don't have code on AEMIF CS2 for the DSP, what > exactly is the DSP doing at reset time (when SW3-4 is "on")? > Is it booting "garbage" and "crashing" (and then the ARM > re-initializes it before running demos)? If it > *is* crashing at boot, isn't there a chance (because of > shared memory) that the DSP crash would wipe-out ARM > codespace/variables?
You are correct in your statement above, following reset the DSP will try to boot from AEMIF, which could potentially be bad if you do not have any valid DSP code in memory at address 0x42200000. However, looking at the u-boot code (u-boot-1.1.3/boards/davinci/platform.S), u-boot does place the DSP back into reset shortly after reset (the comments in this file mentioning "GEM" refer to the DSP). So in reality the DSP will only be active for a short duration before the ARM places it back in reset. Now ideally, if we are using codec_engine/dsplink, we should always have the DSP configure for ARM-boot as the DSP boot is controlled by the ARM. I believe that Loc mentioned in his email that we have identified the reason why the ARM boot mode is not working and this will be corrected. > It really seems that you'd only want "DSP self boot" if there > is in fact something connected to CS2 with DSP code. Maybe > I'm missing something, though. I agree, we should only use DSP self-boot mode if you have valid code in the CS2 space for the DSP to execute. Cheers, Jon _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
