[ECOS] Documentation for .ldi file?

[ECOS] Documentation for .ldi file?

[Grant Edwards]

Can somebody please point me to the documentation for writing a .ldi
file?  I'm trying figure out how to

  1) Add a new section that's always at the beginning of the binary
     image which contains the image entry point.

  2) Set the location of the Cortex-M3 interrupt table -- which is
     neither at the beginning of the program image, nor does it
     contain the image entry point.  Is hal_vsr_table the only symbol
     I need to worry about defing to determine the location of the
     M3's VTOR table?

Why the multiple layers of obfuscation when just writing a gnu linker
script would be so much easier?  

I get the impression that somehow all these layers were supposed to
allow people who know nothing about hardware, the Gnu toolchain or
embedded systems development do embedded systems development?

AFAICT, it backfired and just makes it that much harder to create a
port and figure out what's wrong when something doesn't work.
     
-- 
Grant Edwards               grant.b.edwards        Yow! I'm gliding over a
                                  at               NUCLEAR WASTE DUMP near
                              gmail.com            ATLANTA, Georgia!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Documentation for .ldi file?

[Sergei Gavrikov]

Hi Grant

The below is far from your issue (customizing .ldi files for a CORTEX-M
target), rather it is my attempt to enlighten new readers on, What those
mlt/ldi files are?

On Mon, 16 Sep 2013, Grant Edwards wrote:

> Can somebody please point me to the documentation for writing a .ldi
> file? ...
 
[snip]

Really, it is very conspiratorial thing :-)

Even if we grep for (\<mlt|ldi\>) in the up-to-date eCos SGML files we
find only 2 pages

  http://ecos.sourceware.org/docs-latest/user-guide/install-tree.html
  http://ecos.sourceware.org/docs-latest/user-guide/modifying-the-memory-layout.html

MLT? http://ecos.sourceware.org/fom/ecos?_recurse=1&file=73#file_93

Fortunately, we can dig a bit more, if we take a look on user guides for
previous eCos releases, for example we can find MLT's look and feel

  http://ecos.sourceware.org/docs-1.3.1/guides/user-guides.7.html

IMO, eCos topics by the subject do lack a few important things

1) paltoform .ldi files (named "linker script fragments") write itself
   in C (they are CPP macros) and they will be processed then by CPP.
   Those C macros are defined in <arch>.ld file (see below).
2) any hal/<arch>/arch/current/src/<arch>.ld file includes that "linker
   script fragment" as

   #include <pkgconf/system.h>
   #include CYGHWR_MEMORY_LAYOUT_LDI

3) <arch>.ld (arm.ld, cortexm.ld, etc.) is not linker script, that is
   also C source, the source which will be post-processed then by CPP
   and we get $(PREFIX)/lib/target.ld script (real linker script for
   target). How it gets itself? You can GCC in CPP-mode (after `make
   headers' phase) to see result output

   <TARGET>-gcc -E -P -xc -I<PREFIX>/include \
           $(ECOS_REPOSITORY)/hal/<arch>/arch/current/src/<arch>.ld

   For example

   # output `target.ld' for leon
   sparc-elf-gcc -E -P -xc -Iinstall/include \
           $ECOS_REPOSITORY/hal/sparc/arch/current/src/sparc.ld

Q: Can somebody please point me to the documentation for writing a .ldi
   file?

A: You need to learn your <arch>.ld to known what those SECTION_* macros
   are and how to use them in the place then you will be able to get own
   memory layout in C. N.B.: But, look on the existing .ldi files first!

> Why the multiple layers of obfuscation when just writing a gnu linker
> script would be so much easier?

As eCos ".ld files" are not linker scripts (they are written in C and
they post-process itself with CPP) it is "easier" to customize a final
linker script (target.ld). Not easier? :-) Thus, eCos ".ld files" let us
to get complex target.ld using a few lines of macros (well, in most
cases). More that, include

   #include <pkgconf/system.h>

lets us to use CDL values (substitute those values and get them in our
`target.ld' script). And at the end eCos experts (hats off) gave us the
complex <arch>.ld files as an excellent code base for usage! So, every
memory layout file can re-use that code. Grant, what you mean, "much
easier"? Much easier to write own GNU linker scripts for own platform?

  $EDITOR target.ld ;# IMO, $EDITOR mlt*ldi "easier" :-)

> I get the impression that somehow all these layers were supposed to
> allow people who know nothing about hardware, the Gnu toolchain or
> embedded systems development do embedded systems development?
 
Disagree. See above. Any <arch>.ld make you to know gory details. That
"allow people who know nothing about hardware" was at the time of
CT1+MLT

  http://ecos.sourceware.org/docs-1.3.1/guides/pix/memorywin.gif
  http://ecos.sourceware.org/docs-1.3.1/guides/pix/regprops.gif
  http://ecos.sourceware.org/docs-1.3.1/guides/pix/memregions.gif
  http://ecos.sourceware.org/docs-1.3.1/guides/pix/memreloc.gif

IMO, that was not bad thing (I would s/know nothing/known a little/. So
far, CT2 resist on using $EDITOR, it's not a bug, it's a feature :-)

> AFAICT, it backfired and just makes it that much harder to create a
> port and figure out what's wrong when something doesn't work.

I am not arguing here that creating and testing non-trivial (not c&p)
memory layout files is easy walk, but, I think that using syntax of GNU
linker script in the place would not help much, at least, you may
temporarily edit <PREFIX>/lib/target.ld (bad advice?) and build/test
executable before editing .ldi.

By the way, cortexm.ld has USER_SECTION macro (arm.ld lacks)

  #define USER_SECTION(_name_, _region_,  _vma_, _lma_) \
      ._name_ _vma_ : _lma_ \
      { __ ## _name_ ## _start = ABSOLUTE (.); \
       *(._name_*) \
      __ ## _name_ ## _end = ABSOLUTE (.); } \
      > _region_

I must confess I have not used it. But, it seems this macro gives more
freedom for .ldi designers.

HTH

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Documentation for .ldi file?

[Grant Edwards]

On 2013-09-16, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:

>   http://ecos.sourceware.org/docs-latest/user-guide/install-tree.html
>   http://ecos.sourceware.org/docs-latest/user-guide/modifying-the-memory-layout.html
>
> MLT? http://ecos.sourceware.org/fom/ecos?_recurse=1&file=73#file_93
>
> Fortunately, we can dig a bit more, if we take a look on user guides for
> previous eCos releases, for example we can find MLT's look and feel
>
>   http://ecos.sourceware.org/docs-1.3.1/guides/user-guides.7.html

Thanks for the pointers.  I had forgotten there was supposed to be
some GUI memory layout tool that auto-generated stuff.



> By the way, cortexm.ld has USER_SECTION macro (arm.ld lacks)
>
>   #define USER_SECTION(_name_, _region_,  _vma_, _lma_) \
>       ._name_ _vma_ : _lma_ \
>       { __ ## _name_ ## _start = ABSOLUTE (.); \
>        *(._name_*) \
>       __ ## _name_ ## _end = ABSOLUTE (.); } \
>       > _region_
>
> I must confess I have not used it. But, it seems this macro gives more
> freedom for .ldi designers.

That looks like what I needed.  In the end, I just put some absolute
symbol assignments in my .ldi file to get the vector table located in
the right spot, while the "vectors" section contains only the
program's entry point.  It's ugly, but it works.  One day I'll have to
try to fix it so that I use a USER_SECTION for the vectors.

-- 
Grant Edwards               grant.b.edwards        Yow! !  I'm in a very
                                  at               clever and adorable INSANE
                              gmail.com            ASYLUM!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss