When the device is powered on, it starts execution from DSP ROM. ARM is in in the disable state at this moment.
The DSP ROM code will Read certain registers to know that ARM is present. (Otherwise it will be a DSP-only boot) Program PDSP0 to prepare for ARM reset vector.
Bring ARM out of reset and let ARM starts execution from its ROM. (Yes, that’s the main difference from OMAPL137 silicon 1.x. ARM has its own ROM and will master the boot process afterwards)
DSP stills in the idle loop.
ARM starts execution from its ROM. It will Put DSP into disable state (probably local reset).
Initialize HW, i.e. PSC, PLL, external memory etc. Read bootcfg registers to decide what boot mode it will be and load and run ARM UBL from appropriate boot media, i.e. SPI flash, NAND, NOR etc.
ARM UBL starts running. Its behavior is totally defined by the SW. For example, TI provided ARM UBL will load and run UBOOT which will further load and run Linux. The Linux application can load and run DSP.out via DSPLINK. This model is the same as DaVinci model.
Industrial customers can choose to load and run a DSP AIS image in certain boot media. Meanwhile ARM UBL also starts booting UBOOT and Linux. In that way, DSP can start processing data before Linux finishing boot.