Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I run arm-none-eabi-objcopy -O binary add.elf add.bin everything seems to be ok. But, later when I run ls -lh add.bin add.elf this is the output I received:

-rw-r--r-- 1 david david 2,6G nov 23 22:49 add.bin
-rwxr-xr-x 1 david david 65K nov 23 22:40 add.elf

this is a huge file. But when I run du -h add.bin the output is:

8,0K    add.bin

What's happening here?

Edit: Output of arm-none-eabi -A -t -x add.bin:

 Warning: could not locate 'add.bin'.  reason: Value too large for defined data type

Output of arm-none-eabi -A -t -x add.elf:

section           size         addr
.text             0x2c          0x0
.data              0xc   0xa0000000
.ARM.attributes   0x14          0x0
Total             0x4c

Output of du -bh add.bin:

2,6G    add.bin

This is how I fixed it:

Initially when I link the program with the command arm-none-eabi-ld -Tld_script.lds -o add.elf add.o the ld script file ld_script.lds contains this:

        . = 0x00000000;
        .text : { 
                * (.text); 

        . = 0xA0000000;  /* RAM starting address */
        .data :{ 
                * (.data); 

The above code fills from 0x00000000 to 0xA0000000 with 0s. This error can be solved the following way:

        . = 0x00000000;
        .text : { 
                * (.text); 
        flash_sdata = .; /* Start data in flash right after the text */

        . = 0xA0000000;  /* RAM starting address */
        ram_sdata = .;

        /* AT specifies the load addr. of .data section */
        .data : AT (flash_sdata) { 
                * (.data); 
        ram_edata = .;   /* Address of end of data in RAM */
        data_size = ram_edata - ram_sdata;

And then in the source I added a piece to copy the data from Flash to RAM. Something like this:

        @ Copy data to RAM.
        ldr   r0, =flash_sdata
        ldr   r1, =ram_sdata
        ldr   r2, =data_size

        ldrb  r4, [r0], #1
        strb  r4, [r1], #1
        subs  r2, r2, #1
        bne   copy

If my English is not too precise, this is the link which helps me to fix the problem. (And a good site for learning ARM embedded programming).

share|improve this question
This thread sounds like it's related to your Q: embdev.net/topic/150574 – slm Nov 23 '13 at 22:11
On the surface this looks like either the resulting .bin file isn't getting compressed or it's including memory (.data) sections in your .bin file that are causing it to be sized inappropriately too large. – slm Nov 23 '13 at 22:12
What does this command report for the resulting files? arm-none-eabi-size.exe -A -t -x <file>. – slm Nov 23 '13 at 22:14
What's the output of du -bh add.bin? – Michael Kjörling Nov 23 '13 at 22:51
up vote 7 down vote accepted

I suppose that add.bin is a sparse file.

Most unix file systems support sparse files (of almost arbitrary sizes). Basically, you can seek to an arbitrary offset before starting to write, and the blocks you skip over will not actually be mapped to disk. If you try to read them, they'll be full of 0s. If you write to them, they'll magically spring into existence (but only the ones you write to).

Here's an example:

$ dd of=sparse obs=1K seek=1M if=<(echo foo)
0+1 records in
0+1 records out
4 bytes (4 B) copied, 0.000411909 s, 9.7 kB/s
$ ls -lh sparse
-rw-r--r-- 1 rici rici 1.1G Nov 23 17:22 sparse
$ du -h sparse
4.0K    sparse

The file I created has one 4 kilobyte block on disk, of which only the first four characters are used. But if you read the file in the normal fashion (sequentially from the beginning) you'll have to read through a gigabyte of zeros before you encounter the foo.

On Linux, du is normally able to report the actual disk usage of a sparse file. You can tell it to report the "apparent size" (which will be more similar to what ls -l reports) by passing it the -b option. That's a Gnu extension; Posix does not require du to be accurate in its reporting of sparse file sizes. ("It is up to the implementation to define exactly how accurate its methods are.")

Presumably, arm-none-eabi-objcopy does something rather similar to the dd example above, in that it expands the ELF-formatted exe into a RAM image, and populates the image by seeking rather than filling the file with zeros. This is, in fact, the classic use case for sparse files, which can be memory-mapped (mmap) without incurring a cost for unused blocks.

share|improve this answer
The links I referenced were basically saying this. – slm Nov 23 '13 at 22:21
@slm: I only see one link; I skimmed through the first couple of screenfulls, but didn't see anything relevant. – rici Nov 23 '13 at 22:25
Yeah that's why I said it was "basically" saying this. You said it more concisely but lines like this: "I'd guess you requested the bin file to contain both RAM and FLASH area." are essentially saying that the file is loaded with sparse data. There's this SO link that I hadn't referenced here either yet: stackoverflow.com/questions/9725268/…. Your answer is the "what", but we're still missing the "why". – slm Nov 23 '13 at 22:31
Well, I fixed it. The problem was the linker script. Effectively, objcopy was filling add.bin with zeros from the address 0x0000002c to 0xa000000. Thanks to all. – David Martínez Nov 23 '13 at 23:19
@MichaelKjörling: A persian king sought a partner for his daughter. Three suitors applied. The king took them to his orange grove, where they sat at the side of his lake. A giant orange tree arched overhead. The king squinted at the lake, and asked, "what's that floating in the shade of the tree?". "Why, it's an orange," said the first suitor. The second looked carefully at the fruit, and responded, "No, it's a lemon." The third suitor waded out to the fruit and picked it up. "It's half of a lemon," he reported... Sometimes it is best to not to be too certain about what you think you see. – rici Nov 23 '13 at 23:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.