TMS320C6678: C6000 boot magic address changes .text

John,

For Boot magic address stuff, please refer the steps given in this FAQ.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1107106/faq-tms320c6657-how-to-wake-the-second-core-by-the-first-core-in-c6657-what-is-boot-magic-address-jump-boot-address

Regards

Shankari G

Thanks for that info. I have further debugged this issue and isolated where/when the corruption is occurring.

We are loading many memory segments into L2SRAM and "PROGRAM". It appears there is no protection if the L2SRAM usage by an application grows to overlap 0x87FF80 to 0x87FFFF? Is this something you expect could happen, and how might we protect against it or atleast fail to compile in these instances?

What does "PROGRAM" map to if used in app.cfg? I suspect its L2SRAMwhich is also mapped to 0x9000XXXX?

We have our platform.xdc setup to map program to 0x90000000 but that address is not documented in the data sheet.

                ["PROGRAM",
                     {
                        name: "PROGRAM",
                        base: 0x90000000,                    
                        len: 0x10000000,                    
                        space: "code/data",
                        access: "RWX",
                     }
                ],

Initially 90000000 seems to map to L2SRM up through 87FFFF, changes to one affects the other. I cannot tell where the remaining memory after actually resides. I am not sure what the 0x90000000 address is doing, can you please elaborate on this behavior and why RLB memory is allowed to be reused like this?

Thank You

John,

Let me look at it and get back.

Regards

Shankari G

John,

Please have a look at this memory map of Platform_test code where the code snippet of Boot magic address is implemented.

Meanwhile, I will have a closer look on yours.

Compare the memory section with yours....

/*
 *  Linker command file
 *
 */

-c
-heap  0x41000
-stack 0xa000

/* Memory Map 1 - the default */
MEMORY
{
    L1PSRAM (RWX)  : org = 0x0E00000, len = 0x7FFF
    L1DSRAM (RWX)  : org = 0x0F00000, len = 0x7FFF 

    L2SRAM (RWX)   : org = 0x0800000, len = 0x080000
    MSMCSRAM (RWX) : org = 0xc000000, len = 0x100000
    DDR3 (RWX)     : org = 0x80000000,len = 0x20000000
}



SECTIONS
{
    .csl_vect   >       MSMCSRAM
    .text       >       MSMCSRAM
    GROUP (NEAR_DP)
    {
    .neardata
    .rodata
    .bss
    } load > MSMCSRAM
    .stack      >       MSMCSRAM
    .cinit      >       MSMCSRAM
    .cio        >       MSMCSRAM
    .const      >       MSMCSRAM
    .data       >       MSMCSRAM
    .switch     >       MSMCSRAM
    .sysmem     >       MSMCSRAM
    .far        >       MSMCSRAM
    .testMem    >       MSMCSRAM
    .fardata    >       MSMCSRAM
    platform_lib > 		MSMCSRAM
}

Regards

Shankari G 

Thank you! I am mostly interested in the 0x90000000 address and what that is actually doing. Part of the data is showing up in L2SRAM but the map file has an address of 0x90000xxxx. I do not know where the remaining 0x90000000 data is in memory assuming that address is virtual and does not really exist.

I do not know why we are using the 0x90000000 address or where the previous developer got it.

Somehow the 0x90000000 Address is getting mapped to L2SRAM.

In the compiler generated map file its reported as 0x900xxxxx in the debugger if L2SRM 0x85ffff is displayed and I page up and down the addresses glitch and bounces between the 0x9000000 and 0x86xxxx perspectives.

When this occurs the Bootloader section in L2 SRAM (Table 2-3 in c6678 datasheet) is being overloaded and corrupted. When the end of L2 SRAM is reached, the 0x9xxxxxxx address space continues on but I cannot tell what memory it is actually using.

John,

By any chance, if you have the C6678 EVM, please tru out the FAQ, I pointed and check whether it jump boots using Boot-Magic.

By this, you will have one working reference assembly code to compare it with yours.

Regards

Shankari G

More information - The 0x9000_0000 address I was looking at is actually DDR memory that seems to be getting cached. We intended to have DDR Caching disabled in our app.cfg via this command
Cache.setMarMeta(0x80000000,0xFFFFFFF,Cache.Mar_DISABLE);

Is there any reason using the debugger or jtag to load would affect how caching is done?

John Connors54 said:

Is there any reason using the debugger or jtag to load would affect how caching is done?

No. not related. 

Have not come across such case from other customers.

===

According to the datasheet, page no: 111, Fig 5-4 :-  L2 memory's Block base address starts at 0x0080 0000h and ends by 0x0087 FFFFh.

For example, address location 0x10800000 is the global base address for C66x CorePac Core 0's L2 memory. C66x CorePac Core 0 can access this location by either using 0x10800000 or 0x00800000.

And Infact, "For C66x CorePac Core 0, as mentioned, this is equivalent to 0x10800000, for C66x CorePac Core 1 this is equivalent to 0x11800000, and for C66x CorePac Core 2 this is equivalent to 0x12800000. "

===

Cache user guide is here: https://www.ti.com/lit/ug/sprugy8/sprugy8.pdf

===

Yes, possibly, the address, 0x90000000 maps to DDR3.

It is even evident in the sample-linker command file, above, with memory map configuration for DDR3. 

MEMORY
{
L1PSRAM (RWX) : org = 0x0E00000, len = 0x7FFF
L1DSRAM (RWX) : org = 0x0F00000, len = 0x7FFF

L2SRAM (RWX) : org = 0x0800000, len = 0x080000
MSMCSRAM (RWX) : org = 0xc000000, len = 0x100000
DDR3 (RWX) : org = 0x80000000,len = 0x20000000
}

====

Please note that the "Table 2-3 Bootloader section in L2 SRAM" starts at address 0x0087 2DC0 and ends at 0x0087FFFF.

Here ----> #define MAGIC_ADDR          0x0087FFFC ( Please note that the boot magic address is the last field in the bootloader section in L2SRAM)

===

But however the boot loader section of L2SRAM (start address 0x0087 2DC0 and end address 0x0087 FFFF)  should not get corrupted.....

If this table gets corrupted, no guarantee of jump boot.

Probably, you may have to find out the root cause of the "boot loader table corruption".

While debugging, upto which point, the corruption doesnot occur? 

==

Regards

Shankari G