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.

Where are the Segment definitions located? Its wrong for Davinci!

Other Parts Discussed in Thread: SYSBIOS

There are segment definitions for SRAM and DDR3_RAM available for you to select when defining a new section in the cfg file, but I don't know where they are getting the address for the SRAM.  It is wrong for the Davinci processors since TI reserved the first 1k for some reason.  It looks like 1 omap device has the ARM RAM split between high and low around that 1k mark, but I guess the rest haven't been using internal sram via the linker, otherwise, I would think someone else would have brought this up.

I've modified every instance I can find in the workspace, project, and install directory.  I'm starting to wonder if its compiled in to a binary...

  • Justin,

    Which DaVinci device are you using?  And which board?

    Scott

  • Dm8148 dev board

  • Justin,

    OK, thanks.  I see what you are saying: in the A8's L3 memory map the first 1K of SRAM should be reserved per the data sheet.

    I'm looking into this...

    Scott

  • If I had to guess, I'd guess TI reserved the first 1k for the bootrom.  Have you made any progress on where to change the define though?

    I was hoping to put my interrupt stack, and maybe my data section, so I just hard coded the start address for each section, but it would be nice to let the linker pick the address so I don't have to manage the sizes of these sections.

    That being said, I found that putting the interrupt stack or data section actually slowed down the performance of the system as opposed to just using ddr3.  So while a single access is slower to ddr3, cacheline performance must be similar if not better when going out to ddr3.  Makes me kind of wonder how I can use the A8 SRAM and have it beneficial.  Thats why I thought the .data section would be a perfect fit, since its not usually sequential access.

  • Justin,

    My first batch of pings on this didn’t get a definitive answer so I’ve sent out more today.  I’ll post back to the forum when I have that.

    My guess is that the current definition in the device configuration files came from a preliminary version of the datasheet that didn’t list that area as reserved.

    I’ve not used this device myself… but I’d think one benefit of using this internal RAM region would be reduced power consumption – by reducing off-chip access to DDR, and maybe eliminating them for a while of reduced activity so that the DDR can be powered down.

    Scott

  • Justin,

    I just received confirmation from the device team that this is a bug in the *datasheet*.  The first 1KB of RAM is *not* a reserved area.

    I just filed a bug report to get the datasheet corrected.

    Sorry for the trouble this has caused you, and thank you for bringing this to our attention!

    Scott

  • I'm not sure this is correct information.  

    I am unable to access this region of memory from the jtag memory browser.  The first address that I can even read is 0x402f0400.  I had tried using the base address to assign my stack for example and the system would not boot, only threw exceptions.  Thats when I pulled up the memory browser and saw a bunch of question marks, then data at 0x402f0400.  I remembered seeing something about this on the datasheet, saw it, made sense that the section is reserved.  However, I couldn't figure out how or where to modify the sysbios definition for the different devices, SRAM, OCMR, DDR3.

  • Justin,

    OK, thanks. :OP

    Looking now, I can see in the DM8148.cmd file linked from the dm8148.xml file that CCS is considering that first 1K as reserved too:

        ARMRAM:       o = 0x402F0400  l = 0x0000FC00  /* 64kB ARM RAM */

    So I’m not surprised that CCS can’t access it given that definition.  If the datasheet is indeed wrong then this needs to be fixed too.

    But I don’t know if this can explain why your program gave a bunch of exceptions when trying to boot.  Those are runtime exceptions versus CCS exceptions?  

    I’ll have to forward this info on and look into this more…

    Scott

  • Justin,

    Sorry for the delay in getting back to you. 

    We’ve run some experiments and confirm that this first 1KB is indeed reserved and not accessible to applications.  I’m still waiting for final word on what this area is reserved for, but it is confirmed to be a reserved area.

    So, the datasheet is correct.  I filed a bug report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=393912) to get this fixed in the device configuration files within XDCtools.

    Thanks again for pointing out this issue.

    Scott

  • So, I guess the workaround is to generate your own board definition?  Or is there a way to correct the address on my machine for that board definition?