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

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.

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

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.

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.