DM6446 BOOT DM6437 through VLYNQ

please note that when DM6437 is in VLYNQ boot mode, application downloaded by host is automatically written to DSPBOOTADDR (see http://focus.ti.com/lit/an/spraag0d/spraag0d.pdf for more details).

I ask that question when I read  http://focus.ti.com/lit/an/spraag0d/spraag0d.pdf .

The ROM bootloader supports boot via VLYNQ with DSP as VLYNQ slave. The bootloader ensures that
VLYNQ is enabled and then polls for BOOTCMPLT.CMPLT flag in the BOOTCMPLT register to indicate
that the download of application by VLYNQ Host is complete. The bootloader will then branch to the start
address in DSPBOOTADDR as written by the VLYNQ Host. The boot process for VLYNQ then is as
follows:
1. If FASTBOOT is enabled bootloader configures PLL according using appropriate PLL multiplier.
2. Bootloader makes sure VLYNQ is enabled.
3. Bootloader executes empty loop polling for BOOTCMPLT.CMPLT flag.
4. VLYNQ Host downloads application to DSP.
5. VLYNQ Host writes application start address to DSPBOOTADDR register.
6. VLYNQ Host writes 1 to BOOTMCPLT.CMPLT register flag.
7. Bootloader detects BOOTCMPLT.CMPLT and branches to start address in DSPBOOTADDR.

I dark some content when I copy them from spraag0d.pdf .

I was confused by your answer. You said "application downloaded by host is automatically written to DSPBOOTADDR".

But the document says the start address to DSPBOOTADDR register should be written by VLYNQ Host(in my platform, the host is DM6446) as the above dark content "5".

So I think the DSPBOOTADDR should be changed by VLYNQ Host.

The VLYNQ boot works much like any of the other master boot modes such as a HPI or PCI boot, where the master loads everything onto the device being booted and gives it a signal to run.

The confusion here seems to be coming from the 'VLYNQ remote memory map' address space, this is where the local device can act as a master over the remote device, this is not the only space that the remote device can access. The remote master DM6446 device can load the slave DM6437 in its entirety, it is not limited to the 0x4C000000 space because the space it accesses on the DM6437 can be shifted around using the RAMO and RAMS registers described in SPRU938. I think the key piece of information you are missing is that you can access these VLYNQ configuration registers on the DM6437 from the DM6446 host by accessing the second 128 bytes in the VLYNQ control register map, see section 3 of SPRU938, this allows you to slide around the VLYNQ 'windows' into the remote DM6437 device, allowing you to write to all of the memory when loading your program.

After having loaded everything the last things you do will be to write the application start address to DSPBOOTADDR  so the DM6437 knows where to execute and then the BOOTCMPLT bit to initiate the execution of the freshly loaded application.

I hope this helps to clear things up, I have not gone through a VLYNQ boot process myself but VLYNQ is often easier than it sounds since the communication layers are abstracted, the software interface to it should be relatively simple.

Bernie Thompson said:

The confusion here seems to be coming from the 'VLYNQ remote memory map' address space, this is where the local device can act as a master over the remote device, this is not the only space that the remote device can access. The remote master DM6446 device can load the slave DM6437 in its entirety, it is not limited to the 0x4C000000 space because the space it accesses on the DM6437 can be shifted around using the RAMO and RAMS registers described in SPRU938.

I was just expecting the answer. Then I can visit all the memory space of DM6437 through VLYNQ. If I want to write the application start address to DSPBOOTADDR, I only need to map the address 0x01C4 0008(address of DSPBOOTADDR in DM6437) to DM6446 through the second 128 bytes in the VLYNQ control register map. I will try it immediately.

NINGMENG CHEN said:

DM6437's VLYNQ Remote Memory Map is 4C00 0000h： 4FFF FFFFh

DM6446‘s VLYNQ Remote Memory Map is 0C00 0000h： 0CFF FFFFh.

DM6446 acts as host and DM6437 acts as slave.

Does it mean DM6446 can only downloads application to 4C00 0000h： 4FFF FFFFh of  DM6437's Memory?

No.  The DM6446 has a VLYNQ (Remote) region, in its own memory map located at 0x0C00 0000h through 0x0CFF FFFFh.  This is a window into the DM6437's memory space which can be defined by the VLYNQ configuration registers.  Please take a look at the TMS320DM644x DMSoC VLYNQ Port User's Guide (SPRUE36) in Figure 7.  Sometimes illustratations are better than just a text description.  Section 2.9 in general talks about address translation.  You need to configure the VLYNQ peripheral on both the DM6446 and DM6437 to properly translate addresses from the DM6446 memory map to the DM6437 memory map.  This is done in hardware for you, provide it is configured correctly.

Page 18 and 19 of SPRUE36 actually have a decent example of how the address translation works.

NINGMENG CHEN said:

But the address of DSPBOOTADDR in DM6437 is 0x01C4 0008, the address of BOOTCMPLTin DM6437 is 0x01C4 000C. The address was not between 4C00 0000h and 4FFF FFFFh. How to visit these two registers?

Or DM6446 can visit any memory of DM6437?

As mentioned above, address translation needs to occur in order to make the DM6437 memory space visible to the DM6446's 0x4C000000-0x4FFFFFFF window.