Place RW Compression Data

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

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.

Hi IB,

This may be a game of semantics but I don't agree with this wording:

The value 0x77 of your example does not initially exist in the RW section.

Either I'm not understanding you correctly or I think you may not be completely clear on what the scatter loading section attributes mean.

From my understanding the 0x77 IS my RW section. The Load (ex. ROM) and Execute (ex. RAM) regions have nothing to do with what is part of the RW, RO, ZI sections.

The automagic section of code you are referring to is part of the C library initialization. As you say this is code that is place by the linker that copies the Load Region to the Execution region. (Note: You can also place this code where you like as long as it's Load and Execute are at the same location)

To be completely explicit in my understanding this is how I've come to understand scatter loading.

Take the above example and call this "test.o". test.o will have the following:

An RO section = the code instructions
An RW section = the non-zero init data (namely the 0x77)
And (possibly) a ZI section = equal to all the zero initialize RW variables...

Now the scatter loading has 2 regions a Load region and an Execute region.

In most cases (as you pointed out) the Load region refers to ROM and generally the Execution Region Refers to both ROM and RAM.

For example the most common scenario is that the Load Section RO,RW,ZI regions are all in internal flash and during execution the RW and ZI are copied decompressed to internal RAM.

Now the kicker. The RO section in "Load View" looks the same as in "Execution View" BUT the RW and ZI sections probably do not.
In "load view" (i.e. the firmware image) The RW section is often compressed and placed right after the RO section. The ZI section normally consists of a start address and length.
In "Execution View" (right after the copy by __main) the RO section stays in internal flash and the RW section that is in the flash is decompressed into the RAM. The ZI section that consisted of a start and length is zeroed in RAM.

I totally realize you understand most of this I just object to associating ROM or RAM with the section attributes RO, RW as I do not believe they are related.
A common scenario (especially in debug) is to have all the Regions in RAM (Load and Execute) Thus all the sections in both "views" are in RAM.

I hope this clarifies my understanding and maybe highlights were are understanding differs?

M

"Either I'm not understanding you correctly or I think you may not be completely clear on what the scatter loading section attributes mean."

One thing I could not do is claim to be an expert on the scatter loading file, it's syntax or it's facilities!

"From my understanding the 0x77 IS my RW section."

I would say "not quite". The location of it may well me in the RW section, but 'something' has to initialise that location. The 'something' is the scatter loader and the scatter loader reads the information it has to use from the 'extra' section (which I referred to before).

Maybe we're discussing the same thing, but from slightly different viewpoints.

If you were to single step through the startup as I suggested, and watch the variable you expect to see the value 0x77 in, I think you will see the variable get written as part of the startup.

We must be saying the same thing just in circles...
The 0x77 IS the RW section (I'm almost sure of this)

Basically Figure 2 on this page says it all:

http://www.keil.com/support/man/docs/armlink/armlink_Bhchdbih.htm

The important thing is to realize the the Load View has an RW section and the Execution View has an RW section and they do not have to be at the same place but both are still the RW sections.

The code that moves/copies/decompresses the regions that don't have the same Load and Execute locations is the C lib init code. I've single stepped through this code may time :)

Cheers,

M

"We must be saying the same thing just in circles..."

Yes, I think we are ;)

However, I have to admit that you've made me revisit and rethink the topic - My original requirement changed a little and the challenge went away.

When I get a chance, I would like to re-examine the whole area keeping your comments to hand.

Cheers.