Place RW Compression Data

Wouldn't it be the same way you place uncompressed RW data?

I don't think the fact it is compressed makes it placement in the Load Regio any different.

The Execute region will obviously need to be large enough for the uncompressed data.

If you have a scatter file you are working on and want to post it I might be able to explain a little.

M

Wouldn't it be the same way you place uncompressed RW data?

I don't think the fact it is compressed makes it placement in the Load Regio any different.

The Execute region will obviously need to be large enough for the uncompressed data.

If you have a scatter file you are working on and want to post it I might be able to explain a little.

M

I don't know how to address the RW compressed data to place it since this is being handled by the linker.

For example, if I have a simple scat file

LOAD_ROM 0x0
{ VECTORS +0 { *(.romvectors) }

CODE +0 { *(+RO) }

...
ram execution regions
...
}

the compressed data is placed after the CODE

You can use an ANY section.

For example:

LOAD_ROM 0x0
{ VECTORS +0 { *(.romvectors) }

CODE +0 { *(+RO) }

 RAM_EXEC 0xA0000000 0x01000000 ; SDRAM
  {
    .ANY (+RW)
  }
}

so I left out the ram region specification

RAM_DATA +1 { * (+RW, +ZI) }

how the compressed RW data (ram initialization data) is not placed in RAM, it is placed in flash (as desired); but I cannot figure out how to specify a region for the compressed RW data (so I control it's location instead of the linker just placing at the end).

I think the rw compressed data is actually RO data; I don't know why it is not placed in the CODE execution region.

I asked a similar question a while ago:

http://www.keil.com/forum/16898/

It also looks like someone asked a similar question and got an answer at:

http://www.keil.com/forum/17373/

thank you!

I saw that question but I missed the key points:
the RW compression data is placed in the load region where the compressed data is from so
adding a second load region correctly places code after the RW compressed data.

I don't understand what the Compressed has to do with the placement?

@IB Shy - I read your previous question (linked above) I don't understant what you were trying to do. Did you figure it out?
Based on your original post (desired layout) I don't see why Roger Ivie answer would not have worked?

The Load address are where the data lives in the image so you can just use as many load regions as you want to place any and all sections. The execution addresses are were the data gets copied/decompressed to.
I'm obviously not getting something and would appreciate a clarification even if it's just so I can better understand.

Thanks.

M

when the compressor is enabled, it will compress ram initialization data. This is the data I was calling 'RW compressed data', but it's really RO data the the uncompresseor uses to initialize ram.

I don't know how to place the 'RW compressed data' explicitly. However, the other post showed that the 'RW compressed data' is placed in the load region it is from, so by creating a 2nd load region, I was able to place data after the automatically placed 'RW compressed data'

This solves my immediate problem, although I'd still like to know if I can explicitly place the 'RW compressed data'

Are you sure that RW compressed data somehow becomes part of the RO section for the linker? I don't think that would make sense?

Note: I do understand that the RW initialization data must be stored somewhere in the Load Region and my understanding is that this section is referred to as RW (compressed or not)

Please let me know if this is not your understanding.

reference:
infocenter.arm.com/.../index.jsp

intuitively that is not my understanding. Since the initialization data will not change, it can be RO.

primarily I am considering initialization data for static module vars

simple example

static uint8 exampleStateFlag = 0x0;

void exampleStateHandler(void)
{
  if (exampleStateFlag)
  {
      /* does something */
  }
}

that 0x0 has to be stored somewhere and it is not volatile so it seems it should be stored in RO

hmm.. That is definitely not my understanding.

One because it initializes to zero this would probably form part of the ZI section not the RW section.

Second if it was for example:

static uint8 exampleStateFlag = 0x77;

void exampleStateHandler(void)
{
  if (exampleStateFlag)
  {
      /* does something */
  }
}

Than I believe that this would be stored in a section called RW. (Otherwise I have no idea what would go in RW sections.)

Check this link:
infocenter.arm.com/.../index.jsp
particularly the "area-attrs" section.

static uint8 exampleStateFlag = 0x77;

void exampleStateHandler(void)
{
  if (exampleStateFlag)
  {
      /* does something */
  }
}

"Than I believe that this would be stored in a section called RW. (Otherwise I have no idea what would go in RW sections.)"

You are both right and not right.

Remember that the image might be initially stored in some nov-volatile area (e.g., ROM).

Where is that static initialised variables stored?

Answer: It will be stored as part of the image in that non-volatile area and copied from there to the volatile area (e.g., RAM) as part of the startup code.

The linker takes all the initialised data that exists in the RW section and automagically adds some code to the executable.

The linker might choose to compress this data or not. Also, if there is ZI data, it might simply put a size for those areas - The startup then does a block fill of 0x00 for these areas.

Well, that's a swift and rather basic description of what occurs.

It is the position of the data that the linker creates in the executable image which I refer(red) to.

Hi IB Shy,

I think this is exactly my point. There seems to be a confusion of some real ROM memory and what an RO region means.

In the example above the variable initial value (0x77) would be stored in the RW section of the region. The region in turn could refer to either ROM, RAM whatever.

What I was getting at is that the compressed/uncompressed initialization data is referred to as the RW part of a section. (And hence has nothing to do with whether or not it is on non-volatile memory).

I understand what you are saying with regards to position in the executable region but I don't understand why there is any ambiguity in this.

Basically as I understand it there is ultimate flexibility, each section is split into RO, RW and ZI subsections. Each of these can be placed in any Load Region (generally ROM) and any Execution region (generally a mix of ROM and RAM).

For example if I had test.o as a c module I could place it in ROM as a load region and RAM for execution region in which case the code, init, and zero-init section are all copied to RAM before execution or I could execute the code (RO) from the ROM and copy the init and zero-init (RW, ZI) section to RAM.

Option A:

LR_IROM1 0x00040000 0x00040000  ; Internal Flash
{
  ER_IROM1 0x00040000 0x00040000    ; Execute from the internal flash
  {
   *.o (RESET, +First)
  }

  RW_IRAM1 0x10000000 0x00010000    ; Internal RAM
  {
    test.o (+RO +ZI +RW)
  }
}

Option B:

LR_IROM1 0x00040000 0x00040000  ; Internal Flash
{
  ER_IROM1 0x00040000 0x00040000    ; Execute from the internal flash
  {
   *.o (RESET, +First)
   test.o (+RO)
  }

  RW_IRAM1 0x10000000 0x00010000    ; Internal RAM
  {
    test.o (+ZI +RW)
  }
}

Maybe we are all saying the same thing.

My main point is RO, RW, etc as they relate to image sections have nothing to do with volatile/non-volatile storage.

Cheers,

M

Hi Marc,

I don't think we are saying the same thing.

I was talking of ROM and RAM to try and highlight what typically occurs in plenty of embedded environments - Maybe I failed.

The value 0x77 of your example does not initially exist in the RW section. The RW section may well be located in RAM, but it is the responsibility of the startup code to initialise that variable with that value. The startup code does this by having an 'extra' section of data which holds all the values and variable locations. This 'extra' section of code is added automagically by the linker. It is this 'extra' section which I refer to.

As an experiment, you can create a small program with some initialised data and single step through the startup code. At the end, there is code something like:

                IMPORT  __main
                LDR     R0, =__main
                BX      R0

At the assembler level, step into __main. You then see the code that initialises your application's initialised data before it jumps to your main() function.