We are having problems with runtime-sharc-loader utility on our custom board running Linux. When used for the first time after a boot, loadsharc_SC589 utility operates as expected but on further attempts it fails. When using the utility on EZKIT it works as extected on even after the first run.
Our setup is approximately:
- custom board with ADSP-SC589, very similar to ezkit design except only using dmc0 ram
-Linux Add-In for ADSP-SC5xx based linux (uboot and linux ported according to available documentation)
-EE399v03 SharcLoader compiled under buildroot system
-EE399v03 Blinking_Led example for core1 is used for testing,default for ezkit and one modified to use leds on our board
console output when the utility fails is:
Waiting for sharc
time expired waiting for Sharc msg...exiting
This would imply that corecontrol kernel driver is somehow failing to bring the core1 out of reset. Only suspicious thing I can figure out if the driver (arch/arm/mach-sc58x/core_control.c ) is that the silicon anomaly 20000045 behaves quite similarly. But this shouldn't apply, running the version with or without the workaround made no difference. Marking for parts we have are:
-ezkit: BBCZ-4B 4177987.1-1.0 #1811 KOREA
-custom: KBCZ-5B 4219500.1-1.0 #1819 KOREA
so the that silicon anomaly should not apply.
Playing around with the corecontrol utility, running corecontrol --start 1 makes even the first run of loadsharc_SC589 fail
This bug has been baffling me for a while, so I'd be interested if there is something I've missed, or if there is some deeper issue behind all of this. Not being able to reboot DSP cores would have severe impact on fault recovery for our product, so I look forward to hearing from anyone with information.
in the latest Linux add-in 1.3.1 Release notes there is a know issue that seems related to the issue you are experiencing:
Hopefully somebody from ADI will be able to confirm this and provide more info.