arm scatter file

[ashu]

Hi All,
I have some basic questions on scatter file syntax (ARM) which are also related to how programs execute in the CPU.


My basic understanding is the following: every object file contains some sections (like RO, RW and ZI) etc. The linker in turn links multiple object files and puts these sections together and resolves symbolic references etc. This linked executable is the ELF file which is ready for execution.

In the ARM architectures however they go a step further and they say that this linked file is load view of the executable image. The execution view however is different and specified by a scatter file.

Can someone explain to me what is the difference between load and execution view of an image and when would someone multiple load regions(by an example).

regs
ashu

[Hans-Bernhard Bröker]

On 11.03.2013 17:01, ashu wrote:

> My basic understanding is the following: every object file contains
> some sections (like RO, RW and ZI) etc. The linker in turn links
> multiple object files and puts these sections together and resolves
> symbolic references etc. This linked executable is the ELF file which
> is ready for execution.

No, an ELF file is not ready for execution just like that. For
starters, because it's still a _file_, not a memory image of a runnable
program.

Among the reasons for that is that ELF files usually contain a whole lot
of stuff that the CPU neither needs to see, nor should it, like debug
information. And that those pieces of data that the CPU _is_ supposed
to see are still in multiple pieces, at places inside the file that have
little to nothing to do with the actual place they need to be in CPU
memory space.

An ELF file is supposed to be loaded from some kind of storage external
to the CPU (e.g. a hard disk drive), by something like a full-blown
operating system. As their most prominent example, Unix / Linux
programs on disk are ELF files, these days.

> In the ARM architectures however they go a step further

No. That ELF files are not usable as raw executable is pretty much a
universal fact. It is in no way related to the ARM architecture.

[ashu]

Hi Hans,
thanks so much for the information. So the ELF generated by the linker is still not ready for execution but atleast as far as the ARM specification is concerned, they called the linked elf executable. Here is what the ARM Linker utilities guide says "Output from a successful invocation of armlink is one of the following: • an executable image in ELF executable format ".

In any case, my question is what is difference between, load view and execution view of the image?

thanks
regards
ashu

[Niklas Holsti]

On 13-03-12 11:22 , ashu wrote:
> On Monday, March 11, 2013 11:51:10 PM UTC+1, Hans-Bernhard Bröker
> wrote:

[snip info on ELF]

>
> Hi Hans, thanks so much for the information. So the ELF generated by

> the linker is still not ready for execution but at least as far as the

> ARM specification is concerned, they called the linked elf
> executable.

It is common to call an ELF file "executable", because it *contains* the
executable machine code. But it also contains a lot of *other*
information, so you cannot just put the ELF file, byte per byte, into
the processor memory and boot.

> In any case, my question is what is difference between, load view and
> execution view of the image?

There must be a program loader that reads the ELF file, extracts the
machine-code instructions and other memory-initialization data, and puts
the instructions and data in the processor memory, at their correct
addresses (also specified in the ELF file). *Then* execution can start.

See http://en.wikipedia.org/wiki/Executable_and_Linkable_Format and its
references.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[John Devereux]

Niklas Holsti <niklas...@tidorum.invalid> writes:

> On 13-03-12 11:22 , ashu wrote:
>> On Monday, March 11, 2013 11:51:10 PM UTC+1, Hans-Bernhard Bröker
>> wrote:
>
> [snip info on ELF]
>
>>
>> Hi Hans, thanks so much for the information. So the ELF generated by
>> the linker is still not ready for execution but at least as far as the
>> ARM specification is concerned, they called the linked elf
>> executable.
>
> It is common to call an ELF file "executable", because it *contains* the
> executable machine code. But it also contains a lot of *other*
> information, so you cannot just put the ELF file, byte per byte, into
> the processor memory and boot.
>
>> In any case, my question is what is difference between, load view and
>> execution view of the image?
>
> There must be a program loader that reads the ELF file, extracts the
> machine-code instructions and other memory-initialization data, and puts
> the instructions and data in the processor memory, at their correct
> addresses (also specified in the ELF file). *Then* execution can
> start.

Or, for a bare-metal embedded system, one can convert the elf to a
binary image which can be directly executed. For example, for ARM and
gcc toolchain, might be

arm-elf-objcopy -O binary program.elf program.bin

This would convert program.elf to a directly executable file program.bin
which could be loaded into flash memory and executed.

> See http://en.wikipedia.org/wiki/Executable_and_Linkable_Format and its
> references.

--

John Devereux

[ashu]

Hi all,
thanks for all the precious information.
Why do we need two separate views for the image i.e. load view and execution view. Can anyone give me an example where we need two separate load regions and corresponding multiple execution regions?

regs
ashu

[John Devereux]

ashu <ashutosh....@gmail.com> writes:

> On Tuesday, March 12, 2013 12:41:22 PM UTC+1, John Devereux wrote:
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>

[...]

>>
>>
>> Or, for a bare-metal embedded system, one can convert the elf to a
>>
>> binary image which can be directly executed. For example, for ARM and
>>
>> gcc toolchain, might be
>>
>>
>>
>> arm-elf-objcopy -O binary program.elf program.bin
>>
>>
>>
>> This would convert program.elf to a directly executable file program.bin
>>
>> which could be loaded into flash memory and executed.
>>

> Hi all, thanks for all the precious information. Why do we need two
> separate views for the image i.e. load view and execution view. Can
> anyone give me an example where we need two separate load regions and
> corresponding multiple execution regions?

Well, one thing is that .elf would typically contain all the debug
information. You don't want that on a small embedded target because it
takes up too much memory. So you program the .bin binary file into the
target and load up your debugger with the .elf.


--

John Devereux

[Stefan Reuther]

ashu wrote:
> Hi Hans,
> thanks so much for the information. So the ELF generated by the
> linker is still not ready for execution but atleast as far as the ARM
> specification is concerned, they called the linked elf executable.

The ARM CPUs I have come across have some sort of built-in bootloader
that interprets a certain format of data in flash. In its simplest form:
the program image is 0x12345 bytes, and starts at 0x23456. Such a thing
in flash is "executable" to the CPU. An ELF file is not executable for
the CPU alone, it needs some support programs to load.

> Here
> is what the ARM Linker utilities guide says "Output from a successful

> invocation of armlink is one of the following: � an executable image in

> ELF executable format ".
>
> In any case, my question is what is difference between, load view and
> execution view of the image?

The load (linking) view describes what's needed for linking (symbol
names, section names, possible debug information). The execution view
describes what's needed for execution (memory segment attributes, and
that's about all it describes unless you have an executable for an
operating system, where it also refers to shared libraries).

If you make a program to convert an ELF file into that "certain format
of data in flash", you'll probably read the execution view, just because
that's a little simpler.


Stefan

[Robert Wessel]

On Tue, 12 Mar 2013 09:29:42 -0700 (PDT), ashu
<ashutosh....@gmail.com> wrote:

>On Tuesday, March 12, 2013 12:41:22 PM UTC+1, John Devereux wrote:
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>
>>
>>
>> > On 13-03-12 11:22 , ashu wrote:
>>

>> >> On Monday, March 11, 2013 11:51:10 PM UTC+1, Hans-Bernhard Br�ker

For something like an ELF executable, there's an expectation that
there are going to be relocations at load times, and fixups for calls
to shared libraries, etc. Until those happen, the image is not
actually executable. The ELF file contains the information needed to
do that. It can also include things like debug information.

When you're running without an OS, you need to get the executable
relocated and whatnot before you put it on the device, since there's
no one there to do it later.

[Boudewijn Dijkstra]

Op Tue, 12 Mar 2013 17:29:42 +0100 schreef ashu
<ashutosh....@gmail.com>:

> On Tuesday, March 12, 2013 12:41:22 PM UTC+1, John Devereux wrote:
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>> > On 13-03-12 11:22 , ashu wrote:
>> >> On Monday, March 11, 2013 11:51:10 PM UTC+1, Hans-Bernhard Bröker
>> >> wrote:

> [snip]

>> >
> Hi all,
> thanks for all the precious information.
> Why do we need two separate views for the image i.e. load view and
> execution view. Can anyone give me an example where we need two separate
> load regions and corresponding multiple execution regions?

This sounds like a homework question. If you know anything about the
current range of microcontrollers you know that they can have different
(and separate) address spaces and different memory regions which may or
may not allow execution.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/

[Simon Clubley]

The way the OP ignored the response they were replying to and went straight
back to asking the same question also made me think it was homework as
well.

The original question was sufficiently unclear that I also wondered if
the OP was thinking more about the need to relocate .data from flash
address space (assuming a flash based boot) to ram. However, I see that
as having too obvious a answer to be asking about so it's probably not
that.

If it was the OP's actual question however, then I won't answer it directly
in case it's homework, but instead I will ask the OP to think about the
difference between .rodata and .data and what is actually stored in those
sections. _If_ that was your question, it should now be obvious why .data
needs to be relocated to a different, ram based, address during execution.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Tauno Voipio]

On 13.3.13 2:42 , Simon Clubley wrote:
> On 2013-03-13, Boudewijn Dijkstra <sp4mtr4p....@indes.com> wrote:
>> Op Tue, 12 Mar 2013 17:29:42 +0100 schreef ashu
>> <ashutosh....@gmail.com>:
>>> On Tuesday, March 12, 2013 12:41:22 PM UTC+1, John Devereux wrote:
>>>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>>>> On 13-03-12 11:22 , ashu wrote:

>>>>>> On Monday, March 11, 2013 11:51:10 PM UTC+1, Hans-Bernhard Br�ker

IIRC, the idea of a scatter file belongs to the now-discontinued
old ARM toolkit. The toolkit was superseded by the Keil tools,
when ARM bought Keil.

The question about an old toolkit has a strong whiff of homework
and a slightly obsolete professor.

--

-T.

[Grant Edwards]

On 2013-03-13, Robert Wessel <robert...@yahoo.com> wrote:

> For something like an ELF executable, there's an expectation that
> there are going to be relocations at load times, and fixups for calls
> to shared libraries, etc.

There _can_ be those expectations. An ELF file could also contain
nothing but absolutely located sections with no unresolved externals.
In that case it doesn't need to be relocated or linked -- it just
needs to have the section contents copied into memory and is similar
in usage to a hex file or a uImage file.

--
Grant Edwards grant.b.edwards Yow! ... If I had heart
at failure right now,
gmail.com I couldn't be a more
fortunate man!!

[Hans-Bernhard Bröker]

On 13.03.2013 14:53, Tauno Voipio wrote:
> IIRC, the idea of a scatter file belongs to the now-discontinued
> old ARM toolkit. The toolkit was superseded by the Keil tools,
> when ARM bought Keil.

Actually, it's the other way round. As the primary consequence of that
merger, it was Keil's ARM C compiler that was discontinued and
superseded by (a limited edition of) ARM's own "RealView" compiler.

And I think they still use linker scripts (a.k.a. scatter files) --- the
main difference being that in most simple situations Keil's IDE can
generate them on the fly, without the user even knowing about it.

[Tauno Voipio]

OK - Thanks. I abandoned both in favour of the GNU tools.

--

Tauno Voipio