C6748 Bootloader L2 memory requirement

Bump.  Anybody out there?  Bueller?

Yes, you are correct. You need to use the memory to assign uninitialized memory section.

Cheers,
Gagan

Thanks for the confirmation.  I still have a question and comment.

1.  I still don't understand how our current project runs stand alone when a major code section lives in the same area that the bootloader uses.  Any explaination for this?  I want to make sure the documenation is correct, and the memory addresses I have noted above are correct.

2.  It would be a great idea in DSP/BIOS to create this memory section automatically.  If the user selects some combination of RAM / Cache in the TCF file, then this 16kB section gets created with a note field saying, "Bootloader memory, Only load uninitialized DATA only".  TI assumes WAY WAY WAY too many times that projects will only be run on some EVM board via the JTAG / GEL file combination.  Believe it or not, but most customers make their own custom hardware and run stand alone :)

Thanks, Dean

There are actually only a few boot modes that will use the 16KB region in the start of IRAM (I think it is NOR legacy and UHPI).  All boot modes use part of the L1D for their data during the boot, and ROM won't place data its own data in the L2.

The way the boot loader document is written, one would think this restriction applies to very boot mode, but that's not actually true. Your use case is fine.  I will work to get the document updated to be more clear on this point.

Regards, Daniel

Dan,

Thanks for the confirmation.  I thought something like this was happening.  OK, so only certain boot modes use the 16kB block in L2.  Fair enough.  However, you mention that the bootloader uses L1D?  I can't find any information in the C6748 bootloader document about it using L1D.  Please clarify, because if L1D is indeed getting used by the bootloader, I'll need to know the start address and length so I can create a new MEM section.  This new MEM section in L1D would only hold uninitialized data.

- Dean

Dean,

The default L1D state is 100% cache.  During the ROM, we reconfigure this to be 50% cache and use the 16K freed as data, stack, etc. However, before exiting the ROM boot loader, that memory is reconfigured to 100% cache to match it's reset state.  So you shouldn't need to do anything unless you plan to convert that space to be SRAM and use it for your own local data.

Regards, Daniel

Dan,

That is wonderful logic if your application is always run via emulation, or you use the L1D default.  However, the TCF file within DSPBIOS makes it very easy to configure L1D to whatever combination of SRAM / Cache you want for L1D.  For the customers that actually choose to use a portion of L1D as SRAM, where in the documentation does it say that the bootloader uses 16kB of L1D?

Can you please provide the L1D starting address for the 16kB block that the bootloader uses?  I need this info to make a new MEM section, which by the way the TCF file should be smart enough to create on its own once it sees the user has picked something other than 100% cache.

It would helpful if TI would release the ROM bootloader code, so customers can find out these little nuggets of missing documentation information.  We already have to search through (16) Applicaton notes, (38) User Guides, and dozens of Wiki pages, so whats one more source?

Thanks, Dean

Dean Hofstetter said:

That is wonderful logic if your application is always run via emulation, or you use the L1D default.  However, the TCF file within DSPBIOS makes it very easy to configure L1D to whatever combination of SRAM / Cache you want for L1D.  For the customers that actually choose to use a portion of L1D as SRAM, where in the documentation does it say that the bootloader uses 16kB of L1D?

How you configure DSP/Bios to use L1D is irrelevant since you cannot load data to the L1D during the boot.  This would be true even if the boot loader did not in any way use the L1D, since the reset state of the L1D is all cache.  If a DSP/BIOS program is configured (via the TCF) to partition the L1D into part RAM and part cache, that configuration won't happen until the DSP/BIOS application starts running, which happens after boot completes.  So the L1D would always be off limits for loading data during the boot.  The RBL is making use of this fact to use part of the L1D for its own purposes and then restoring the cache to the reset state. So knowing the boot loader is using this region during boot doesn't matter, even if you choose to use that same memory during the run of your application.

Dean Hofstetter said:

It would helpful if TI would release the ROM bootloader code, so customers can find out these little nuggets of missing documentation information.  We already have to search through (16) Applicaton notes, (38) User Guides, and dozens of Wiki pages, so whats one more source?

Unfortunately, the source will not be made available since it contains information regarding security usage for secure versions of these parts.

Dean Hofstetter said:

Can you please provide the L1D starting address for the 16kB block that the bootloader uses?  I need this info to make a new MEM section, which by the way the TCF file should be smart enough to create on its own once it sees the user has picked something other than 100% cache.

This information is available from the datasheet, where you get the device memory map, and the C674x megamodule reference, which states:

"The L1D cache converts L1D memory to cache starting at the highest L1D memory address in L1D region 1 and working downwards."

So the L1D SRAM region (the non-cache part of L1D) will start at the beginning of the L1D region, which according to the datasheet is at 0x00F00000 or 0x11F00000 (local or global address, respectively).  I agree that it's a bit annoying to have to look in two documents for this, but the megamodule guide is generic and is reused across many devices, with all the device specific details staying in the datasheet.

Regards, Daniel

OK, now I'm really confused.  Lets step back for a moment to another TI DSP I've used in the past, the C6421.  The C6421 Bootloader users guide, DOES say it uses 20kB of L1D memory, AND you should only link uninitialized data sections in that area.  So, that document identifies L1D is used AND that you can load data into it at boot.  I do realized the C6421 and the C6748 are completely different cores, but they did evolve up through the same single core C6000 chain.  Thus it is reasonable to assume you CAN load data into L1D during BOOT, and there is nothing in the C6748 documentation that says you CAN'T (at least that I've found).

Now back to the C6748.  If I create a initialized data section (say a table of constants), and attempt to load that into L1D, you are saying that won't work on the C6748?  Nothing in the tool chain will prevent me from doing this (at least I think).  Linker would happily put the table into L1D, and the HEX file process would create an image that contains the table in L1D.  Please comment.

I've found a note on page 24 of the C674x DSP Cache users guide.  I believe it is trying to say, you can't link code/data into L1 sections that default to cache.  You must first load them into L2(or external memory), and then at run time move those sections into the L1 memory areas.  I also see that the C6421 bootloader document specifically says that cache is DISABLED after booting, and that is maybe why it works on the C6421, but not on the C6748.  Am I on the right track?

- Dean

Thanks Daniel for the C6748 education on how the bootloader works with regard to the L1 / L2 memory.  For others reading this, my summary is:

1.  L2 memory is indeed used by the bootloader, BUT only with some of the boot modes.  Hopefully TI will update the C6748 bootloader document so users can see if their boot mode is effected.

2.  If your selected boot mode DOESN'T use the 16kB of L2 memory, do nothing.  Load code / data into L2 without worries.  However, if your boot mode DOES use the 16kB of L2, you must create a new MEM sections for this 16kB chunk.  Within this 16kB L2 chunk, only uninitialized data sections are allowed.

3.  The C6748 also uses L1D memory.  However, since the C6748 L1D memory defaults to 100% cache, and the bootloader leaves it 100% cache when it is finished, you can NEVER load initialized data sections into L1D.  So, if you configure L1D to be a split of cache and RAM using DSPBIOS, be aware you can only load uninitialized data sections in the RAM sections.

4.  Bootloaders are VERY specific to the DSP part.  Just because you were able to load code (or initialized data) into internal memory on DSP part xyz, don't assume you can do the same thing on a different DSP (even if it is a close cousin).  Can't believe I fell victim to the never assume, but hey #@!% happens.

5.  You can play games if you really really want to have initialized data loaded into L1D.  However you must specify different load and run addresses, and then manually move stuff around from your application before using.

6.  It would be helpful if TI updates their bootloader document to further describe what is allowed, and not allowed.  A helpful note might be:  "If you use boot mode xyz, be aware the bootloader uses 16kB of L2 memory (starting at address abc).  Therefore you are not allowed to load code or initialized data into this memory chunk".  Similar notes can be written for L1D / L1P, since those memory block default to 100% cache.

- Dean