This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DVSDK PCI boot and reboot

Standard DM648 PCI boot uses the BOOTADDR and BOOTCMPLT flags to set the booted code running.  However, this relies on the ROM bootloader running after reset. On host systems with reloadable drivers (obviously linux, and less obviously windows), it may be required to reload the same or different DSP code without power cycle, and without resetting the PCI interface.

I can see that MDCTL can be used to stop the CPU during boot, but how can I then have execution resume at the new code entry point or reset vector?

BTW is it really true the that ROM bootloader uses none of L2,, and has its own special workspace RAM elsewhere?

  • What is the kind of situation that will cause a "driver reload" and how is the environment - i.e. DM648 register content cleared?

    Without knowing the exact conditions and operating environment, it is a bit hard to devise a scheme, so following is just an idea.

     It seems to me there are 3 cases: a) disastrous lockup, needs a complete board reset, b) SW hang, needs the old or new DSP code to loaded and restarted and c) SW change, need the DSP code to swap certain functionality 

    For a) a PCI reset will cause DM648 to reset

    For c) a SW schem can be use to swap out certain sections of code via relocatable modules

    For b) one possible solution is to reserve one of the external interrupts for this purpose (GPIO or external interrupts), and one of the PCI base address (like EMIF3B CE2 or CE3) as a handshaking mechanishm to cause the DSP to prepare for a SW change. This scheme will not work if for some reason that interrupt is masked so that the interrupt cannot be generated, or blocked so that it cannot be serviced.

     Address decode logic needs to be added so that if some location within this space is accessed, a signal will be generated and fed to the selected interrupt input. The host driver, in order to reload the DSP, will perform a memory access that will generate the PCI access to this PCI base address location. This will cause the current DSP execution to be interrupted, and the corresponding ISR invoked. The ISR in turn will perform a pre-determined set of handshake with the host driver to coordinate the downloading of the driver (old or new), start address, etc. and branch to this new address.

  • Loc said:

    What is the kind of situation that will cause a "driver reload" and how is the environment - i.e. DM648 register content cleared?

    It is user initiated on the host PC, either upgrading the host driver, or on linux "modprobe -r dm648driver; modprobe dm648driver"