• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 469 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.

Booting from SPI flash on C6747

Fawad Nackvi62335
Expert 1080 points
Other Parts Discussed in Thread: OMAP-L137

The boot loader document for the C6747, sprabb1c.pdf states

Memory Usage: The bootloader uses 16 KB of DSP L2 RAM starting from 0x11800000 for multiple purposes.

This memory should not be used by any initialized section of the user application

How would I guarantee this in a DSP/BIOS application that I want to bootload from a SPI flash.

Thanks,

Fawad

  • 0
    TI__Guru** 116170 points

    Fawad,

    Could you look at the map file for your application to check if the DSP BIOS application is using this section of the memory. If  your application is using this section then you can modify the section definition from the .cfg file. Refer to Karl`s posts here:

    http://e2e.ti.com/support/embedded/bios/f/355/t/94447.aspx#328678

    Regards,

    Rahul

  • 0
    Guru 26430 points

    Strange. My StarterWare DSP code is using all of L2 RAM and it's boots okay. I am using the OMAP-L137(C6747 DSP side only) and SPI0 Flash. I am using D800K001 version which means AIS is not setting up most HW. The sprabb1 document is not real clear on when the 16KB at 0x11800000 is used. Implied that it is only used on NOR boot. Also not clear is the 64KB at 0x11830000 for decompression. Implied that that is required only if AIS compression is enabled. Yet, I cannot see in AISGEN where compression is selected.

  • 0 in reply to Rahul Prabhu
    Expert 1080 points

    Rahul,

    I looked at the map file and I see

     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .vers      0    00000000    00000040     COPY SECTION
                      00000000    00000040     8channelcfg.obj (.vers)

    .prd       0    11800000    00000000     UNINITIALIZED

    .far       0    11800000    00010f5c     UNINITIALIZED

    So the linker is using 10f5c of uninitialized data starting at 0x11800000 which means I am safe? Is this standard for the linker to put uninitialized data from 0x11800000 onwards and as long as this is 16k long I am fine?  I use the whole of the L2 ram as ram without a L2 cache.

    I will look at the link you posted.

    Thanks,

    Fawad

  • 0 in reply to Fawad Nackvi62335
    TI__Guru** 116170 points

    Fawad,

    Please refer to Mariana`s last response here  on the usage of L2RAM in the ROM code.

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/12272/47854.aspx

    and Brad`s response here

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/12218/295668.aspx

    I have checked to confirm that this is true for the D800K005 version of the ROM so you are okay using that area of L2 as long as you are not enabling decompression feature(applies only to D800K001) and as long as you have uninitiialized sections defined in that region(as I see from your map file).

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Guru* 84110 points

    Fawad,

    It is common to put .far in external memory and to try to save internal memory for .bss and .stack and critical code sections, if any.

    There is a linker feature that you could apply within a manually created linker .cmd file that could solve your problem cleanly. Be sure to put this mylink.cmd file in your project folder and check the link order in your Build Properties for the Linker.

    mylink.cmd said:

    SECTIONS {

     .bss: {} > 0x11800000

    }

    The linker will parse all .cmd files for the various directives and then the MEMORY { ... } part. After that, the linker will parse all of the SECTIONS { ... } sections to decide where to put code, going in order (when appropriate) of the linker .cmd file order that you have established. So for this case, it will put the .bss section at the fixed address of 0x11800000, then will start filling in whatever it needs to after that.

    Since the .bss section can easily get up to 64KB, it may be sufficient to overlay with all of the 16KB that could be used under the circumstances that the posts above have covered. Basically, that means this may not be needed but it could be a robust solution depending on whether your .bss is 16KB or larger.

    You could do something similar with .stack, which also tends to be a little large and is handy to keep in internal memory. And there may be some linker command techniques to put .bss and .stack both sequentially after each other, but that would need some study of the Assembly Language Tools Reference Guide to work it out, if needed.

    Regards,
    RandyP