EmbDev.net

Forum: ARM programming with GCC/GNU tools Objcopy pads 0s up to my new section


Author: Euler Megyer (logaritmuseadx)
Posted on:

Rate this post
0 useful
not useful
Nice day Everyone!

Working with a CLPS7312, I try to use the on chip ram for some
variables. Program runs from external ram, mapped to 0x00000000. Up to
now, all uninited variables were in bss located after .text and .data in
external ram. Objcopy made the binary image, not including .bss. After
introducing .ocram in the ld script file and specifying WORD8
Buffer[BSIZE]__attribute__ ((section (".ocram"))) ; the resulting binary
file is bigger, including the space up to ocram filled with 0s. Ocram is
mapped to 0xb00000.
Could you please tell me, what do I need to modify not to fill the image
with zeros?

I use the followings:
in Makefile:
mass: $(USBECG_SRC) mainecg_mass.c Makefile
//MappedSRamBase=0x0
  $(XCC) $(XCFLAGS) $(INCLUDE_S) $(DEFINES_MASS) \
    -Wl,-Ttext,$(MappedSRamBase) -Wl,--section-start,ocram=0xb04000 -o
usbecg_v$(VERSION_MASS)_mass.elf $(USBECG_SRC) mainecg_mass.c 2>err
  $(XOBJDUMP) usbecg_v$(VERSION_MASS)_mass.elf | hex >
usbecg_v$(VERSION_MASS)_mass.lst
  $(XOBJCOPY) -O binary usbecg_v$(VERSION_MASS)_mass.elf
../bin/usbecg_v$(VERSION_MASS)_mass.bin

in the scriptfile:

OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)

SECTIONS
{
  /* first section is .text which is used for code */
/*  . = 0x0000000;*/

  .text : { *cstartup.o (.text) }
  .text :
  {
    *(.text)                   /* remaining code */

    *(.glue_7t) *(.glue_7)
  }
  . = ALIGN(4);
  /* .rodata section which is used for read-only data (constants) */
  .rodata :
  {
    *(.rodata)
  }
  . = ALIGN(4);
  _etext = . ;
  PROVIDE (etext = .);
  /* .data section which is used for initialized data */
  .data : AT (_etext)
  {
    _data = . ;
  *(.fastrun)
  . = ALIGN(4);
    *(.data)
    SORT(CONSTRUCTORS)
  . = ALIGN(4);
  }
  . = ALIGN(4);
  _edata = . ;
   PROVIDE (edata = .);
  /* .bss section which is used for uninitialized data */
  .bss :
  {
    __bss_start = . ;
    _bss_start_ = . ;
    *(.bss)
    *(COMMON)
  }
  . = ALIGN(4);
  _bss_end_ = . ;
  _bss_end_ = . ;
  _end = .;

  .ocram  :
  {
    *(.ocram) ;
  }
  . = ALIGN(4);

    . = ALIGN(4);
   .int_data :
   {
   *(.internal_ram_top)
   }
  PROVIDE (end = .);
}

Thank you!
Megyer

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Binutils and gcc versions?

Please create a minimal example including all needed file for a "make
all" to reproduce this issue and attach it to a message.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Euler Megyer wrote:
> Could you please tell me, what do I need to modify not to fill the image
> with zeros?

Read the documentation perhaps:

arm-elf-objcopy --help

You will see the option: --gap-fill <val>

Clifford

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
>
> You will see the option: --gap-fill <val>
>
Oh, sorry; I see what you mean, it wasn't teh zeros that concern you,
but rather the padding.

A binary image has no way of marking section locations since it is a
flat image of your application, and has no location or addressing
information. The various hex formats have location information, so you
might use those.

An alternative is to run objcopy twice once with --only-section ocram
and again with --remove-section ocram. You will then get two images that
you have to program separately to the required location. This seems
rather error prone to me.

Author: Euler Megyer (logaritmuseadx)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:

> An alternative is to run objcopy twice once with --only-section ocram
> and again with --remove-section ocram. You will then get two images that
> you have to program separately to the required location. This seems
> rather error prone to me.

Thanks, --remove-section .ocram gives the result I need (you need the
dot before ocram!)

> A binary image has no way of marking section locations since it is a
> flat image of your application, and has no location or addressing
> information. The various hex formats have location information, so you
> might use those.

I was wondering if there is a way to treat the ocram section just like
bss, since neither have initialized variables and the bin file does not
contain bss filled with 0s when ocram is not used.

I use the package WinARM20060606.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.