C6472 EMAC Boot example

Randy,

The attached package was built for the C6474 EVM, but the utilities and process for taking a .out file to a bootable format is the same.  The Image handling doc describes the steps and the utilities directory has the needed executables for get the .out file in the right format.  The EMACboot_pc directory contains the pcsendpkt executable for sending the boot image from your pc.

Regards,

Travis

Hi Travis,

The I2C address on EVM is 0x52, so if we use the eeprom_0x50.out will it work.

Regards

Sharath

Sharath,

The source is included with the zip package I posted.  You can modify the

#define EEPROM_SLAVE_ADDR   0x50  /* slave address */

to accomodate what you need and recompile.  Alternatively, if you are using the C6472 low cost EVM, eInfochips already has the I2C writer program compiled.  You can get this at:

http://www.einfochips.com/TI/EVMC6472_SDK_Setup_4_0.exe

Regards,

Travis

Travis,

Thanks a lot 

Regards

Sharath Chandra

Travis:

 Our group is also making use of the EMAC boot portion of this boot_test_package. Thanks!

But I am trying to understand exactly how the DSP knows which core to load this code via EMAC boot. In the 3core examples, I do not see how the boot tables created specify which core to load since they are created the same (.rmd files are the same-just the .out files are different). Is this done when they are merged together or is the core designation in the .out file itself?

So far we have only been working In the Code Composer-emulator environment. In this environment, we can take the .out file and tell the DSP which core(s) to load the application. I do not see that kind of option when generating the EMAC boot packets.

Jon,

I do not know the boot_test_package well enough to say if it has something specific for helping with this.

But the way I expect the multi-core boot to work is to use the global L2 addresses for all of the code and data that will be loaded, such as 0x13800000 and 0x15800000 for cores 3 and 5, resp. The you also have to set the appropriate values in the boot registers, as required for the boot mode you are using.

From the bootloader's perspective, the code and data are not assigned to a core. In CCS, you can load from the perspective of an individual core and can therefore access its Local L2 address space at 0x00800000. But from any other core and from any other bus master (like the EMAC), you can still write to Core3's L2 by writing to 0x13800000. And Core3 can run that code from either the 0x13800000 address range or from its Local L2 address range at 0x00800000.

Is this what you were looking for, or do I need to understand more about the flow you are using?

Jon,

Randy is correct.  The key to making the multi-core boot work, is the fact that the .out  files are based on the global addresses.  The utilities for converting the .out files and merging the .out files into a single boot table don't do anything for targeting a specific core.  They simply create the boot table and put it in the right format, which includes the global addressing.  So the bootloader running from the internal ROM uses core zero.  As packets come in, the bootloader parses the packets and moves the code/data into the memory addresses specified in the boot table.  Once finished loading, the core 0 interrupts the other cores to kick them out of idle and begin code execution.

Regards,

Travis

Hi Travis,

Picking up the conversation, is there a tool that takes multiple .out images and merges them into one single ".bin" file ?

TI posted, a while back, the "bootAssist" utility that conveniently converts .out into .bin (or .h), however that utility is limited to one-to-one (.out-to-.bin) conversion. Is there a  recommended method to achieve multi-to-one .out-to-.bin conversion?

Thanks in advance,

Cheers

Ziad

Ziad,

In an earlier post to this thread, I attached a boot test package which contains an Image_handling_utilities.doc file.  In this document it illustrates how to take multiple .out files and merge them into a single format file that can be loaded into the DSP via one of the boot methods.  It also provides these needed utilities.  This is the only merge technique that I'm aware of.  Please take a look at this and see if it meets your needs.  I'm confused by your reference to ".bin" format, and am not sure if that is equivalent to any of the file extensions used by this boot test package.

Regards,

Travis

.bin is useful when host processor uses a rfs (file system) and multiple DSP images could be stored in the rfs. For reasons of resource management, it's preferable to store these images in binary format (.bin).

TI's boot assist utility already converts .out into .bin but cannot take in several .out files and convert+merge, I was just wondering if there were a recommended way. I'm positive that many other developers out there are have the same implementation requirements.

Alternatively, I can write the conversion to .bin program myself, so no worries.

Cheers

Ziad

Travis-san,

I am interesting your comment. Now, we have some problems for multi-core boot.  The problem is that core 0 running normally after boot, but core 1 and core 2 does not run..

My understanding is that the core 0 move the code and data to other cores after finishing the boot table. At the end of loading, will the core 0 also write the reset vector at 0X128FFFFC - 0x128FFFFF for core 2?  I do not understand the boot of core 1 and 2 after out of reset from core 0. L2Code start address shall be the base adress of L2? for example, 0x12800000 for core 2?

Regards,

Kato

Kato,

Core 0 does not automatically release the other cores from reset after the boot table is loaded.  You have to actually add that functionality to your core 0 code.  What I mean is that once core 0 comes out of reset, the first thing it 's program should do is release the other cores by writing to the Boot_Complete_Stat register bit that corresponds to the other cores.  You can control the start address if  you don't want to use the default L2 address by writing the DSP_Boot_Addrx register as well.

It is similar to the HPI boot description in the boot loader user's guide (section 4.3.2 of http://focus.ti.com/lit/ug/spruec6f/spruec6f.pdf), except instead of an external host writing these registers, core 0's program would do so.

Regards,

Travis