• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1336 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[C674x, Bootloader] Are L1P and L1D configured as cashe ?

Naoki Kawada
Guru 19890 points
Other Parts Discussed in Thread: OMAPL138

Hi,

I have a question about the behavior of C674x Bootloader.

According to Bootloader document, L1D seems to be configured as Full-Cache in emulation boot mode:

E.2 ROMID: D800K003, Silicon Revision 2.0
• Added new default UART and PLL clock settings for UART boot modes. Fixed UART divider to correct
baud rate to be 115200 (from 230400).
• Added support for LPSC and Pinmux configuration via Function Execute commands.
• Removed the locking of the KICK registers that happened at the end of boot. Note that the KICK
registers were disabled in hardware with this silicon revision.
• Updated DSP code to restore L1D cache to default state (full cache) in emulation boot mode.
So how about other boot modes ?
Can I understand L1D and L1P are configured as SRAM in other boot modes ? 
Background:
If L1D and L1P are configured as Cache in bootloader, this means we have to take care about the assignment of initialized sections to
L1D and L1P memory range in application code. 
Best Regards,
Kawada

  • 0
    TI__Guru* 84110 points
    Kawada-san,

    L1D will be used as SRAM during the bootload process for some boot modes. On the exit from the bootloader to the entry point of your loaded program, L1P and L1D will be flushed and will be set to their default states of full cache.

    The note that you have highlighted above was to fix the emulation boot mode to match the other boot modes.

    Yes, you must take care about assigning initialized sections to either L1P or L1D using the bootloader. If your application requires this, you will need to implement your own secondary bootloader to change the cache settings and then initialize those sections. This could also be done as a part of your application so you do not need a full secondary bootloader; in this case, you would initially put those sections elsewhere in memory and then copy them to L1P or L1D after making the changes to the cache settings.

    Regards,
    RandyP
  • 0 in reply to RandyP
    Guru 19890 points
    Hi RandyP,

    Thanks for your reply. Ok, I understood.
    The boot process looks a bit complicated if my user assigns initialized sections to L1D/P RAM. I'm concerned that my customer can do it by themselves. If L1P SRAM is required, it can't be helped, but as for L1D, I think assigning un-initialized sections (just like static work buffers without initial values, heap buffers, or something) can work if user does not make their own secondary bootloader by themselves. Of cause, L1D cache needs to be changed to SRAM at the beginning of application code (i.e., at the top of main()). What do you think of this ?

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    TI__Guru* 83875 points
    Hi Kawada-san
    I am not sure I understand your response / concern to Randy's post. Essentially, even if the on chip boot loader (primary/rom boot loader - RBL) makes use of the L1D as ram instead of cache, before it exits the RBL , it sets the device DSP cache configuration back to what you would see at power on reset of the device i.e. L1P and L1D all cache and L2 all RAM.
    If the customers wants to change L1D to part RAM/part cache or convert part of L2 as cache, these can be done in customer user code.
    Usually it is not recommended to change L1P from cache to RAM.

    If customer is looking for reference code, they can perhaps look at Starteware APIs and code for OMAPL138. We do not have Starterware offering for OMAPL137/C6747 , but the C674x DSP core is identical on these 2 devices and code should be re-useable
    processors.wiki.ti.com/.../StarterWare_01.20.01.01_User_Guide;tisearch=Search-EN#Cache_Management

    Hope this helps.
    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Guru 19890 points
    Hi Mukul,

    Thanks for your reply.
    May be, my English problem. If I gave you some confusions, sorry for that. What i want to say in the previous post was that RBL would not copy data to L1D SRAM (would not crash RBL work area) if application code used L1D SRAM as some user-defined un-initialized sections. So if users want to use L1D as SRAM in their application, it may be easy to realize it if it is okay for users that the usage of L1D SRAM is restricted only for un-initialized buffer, such that a scratch buffer or something. In this case, I thought user didn't have to create their own 2nd bootloader. What users have to do is changing L1D cache to L1D SRAM before the code accesses L1D memory, which the beginning of main() is best place to do it. Of cause, assigning the standard sections, just like .bss into L1D may not be allowed. This is because .bss may be initialized during c-runtime initialization (before main()).

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    TI__Guru** 116170 points

    Hi Kawada-san,

    I checked the ROM memory map and can confirm that L1D is not configured as complete cache when the bootloader is running. L1D (starting from 0x00f04000) is configured as 16Kb cache. The initial 16KB are used for stack, miscellaneous purpose and following 8KB are used as a memory buffer to load page data from NAND during NAND boot. The cached portion of the memory should not be used by any initialized section of the user application.

    But as Mukul mentioned before the RBL exits, it restores the device DSP cache configuration back to what you would see at power on reset of the device i.e. L1P and L1D all cache and L2 all RAM. Inorder to use L1D as SRAM users have to change L1D cache to L1D SRAM as part of the application initialization.


    Regards,
    Rahul

    Note: Secondary bootloader is also an user application so let us not get confused with the terminologies. Code that runs after boot needs to configure L1D as SRAM to access it.

  • 0 in reply to Rahul Prabhu
    Guru 19890 points
    Hello Rahul,

    Thank you for your reply.

    >Note: Secondary bootloader is also an user application so let us not get confused with the terminologies

    Actually, I'm not sure what terminologies/sentences in my posts gave you confusion... I'm always assuming secondary bootloader should be user program. But anyway, I have found the answers in your replies, So I'll close this thread.

    Best Regards,
    kawada