embedded gcc PPC toolchain questions

embedded gcc PPC toolchain questions

[Ron Flory]

  Hello;

  I have several low-level gcc toolchain questions.  I'm not new to
gcc or embedded programming, but this is the fist time I've tried
to use gcc for a stand-alone, non-linux embedded PPC project.

  Apologies in advance if these appear to be a little off-subject.
I welcome redirection to online FAQs or code snippets.  Thanks.

1.  How does one declare distinct data regions with GCC?  Consider
    the case where a separate non-cached memory region is needed
    for CPM/FEC use, I would do something like the following under
    GreenHills C/C++:

     #pragma ghs section data = ".nocacheram"
        static char fec_rbd_alloc[ <some length> ] = { 0 };
        static char fec_tbd_alloc[ <some length> ] = { 0 };
     #pragma ghs section

     Such distinct regions are generally collected and combined
    across modules, so the FEC and CPM drivers would place their
    buffers in the same non-cached area.

2.  Once I have defined and declared such regions, how does one
    instruct the linker to align and padd such regions?  Under
    Greenhills, this would be done in a linker control file, such
    as:

     .nocacheram  align(0x1000)   :
     .evtdata     align(0x1000)   :

       This would align ".nocacheram" on a 4kb boundary, and would
      ensure 4Kb length as well (since the following group was also
      4Kb aligned).

3.  Once I have defined, declared, and aligned these special memory
    regions, how would I determine their base/length?  Again, under
    GreenHills, we would declare:

      extern char __ghsbegin_nocacheram[];
      extern char __ghsend_nocacheram[];

     Which would provide the 'begin' and 'end' address of the region,
    allowing us to set the appropriate MMU attributes for this user-
    defined area.

4.  I know the question of embedded libc comes up often.  For
    the most part, we basically need the 'strxxx' and 'memxxx'
    functions, but 'sprintf' is quite a different critter.  Since
    we are running an 860, we won't have FP support (and we don't
    want to deal with emulation).  Do most folks use a hand-patched
    'sprintf' source file, manually removing the floating-point ops?
    I've looked into this a few years ago (the gcc sprintf source
    file is a horror).  Has the 'ulibc' that i've heard about been
    used with success by anybody on this list for embedded non-linux
    projects?

5.  We have access to many Macraigor 'Raven' BDM interfaces.  I've
    downloaded the x86 Linux support tools for this device.  Has
    anybody had good results with this device and support tools
    under Linux?

6.  OK, please don't flame me on this stupid question.  Does 'as'
    (the assembler) run its source input through the 'cpp' C
    PreProcessor?  I can always pipe through cpp myself with an
    implicit 'make' target if I need to...

  Thank you.

--

Ron Flory, Network Products.
email: mailto:ron.flory@adtran.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: embedded gcc PPC toolchain questions

[Wolfgang Denk]

Dear Ron,

in message <3ED6298C.3070901@adtran.com> you wrote:
>
>   I have several low-level gcc toolchain questions.  I'm not new to

Umm... did you read the info files for GCC and the GNU linker?

>   Apologies in advance if these appear to be a little off-subject.
> I welcome redirection to online FAQs or code snippets.  Thanks.

It is definitely useful to read existing code, too. The Linux  kernel
or the U-Boot bootloader are good places to start.

> 1.  How does one declare distinct data regions with GCC?  Consider

Use __attribute__ ((section("<name>")))

>     the case where a separate non-cached memory region is needed
>     for CPM/FEC use, I would do something like the following under
>     GreenHills C/C++:
>
>      #pragma ghs section data = ".nocacheram"
>         static char fec_rbd_alloc[ <some length> ] = { 0 };
>         static char fec_tbd_alloc[ <some length> ] = { 0 };
>      #pragma ghs section

static char fec_rbd_alloc[ <some length> ] __attribute__ ((section(".nocacheram"))) = { 0 };

etc.

It probably makes sense to define some macros, like this:

#define ___NOCACHERAM__ __attribute__ ((section(".nocacheram")))
...
static char fec_rbd_alloc[ <some length> ] ___NOCACHERAM__ = { 0 };


>      Such distinct regions are generally collected and combined
>     across modules, so the FEC and CPM drivers would place their
>     buffers in the same non-cached area.

Same here.

> 2.  Once I have defined and declared such regions, how does one
>     instruct the linker to align and padd such regions?  Under
>     Greenhills, this would be done in a linker control file, such
>     as:
>
>      .nocacheram  align(0x1000)   :
>      .evtdata     align(0x1000)   :

With GNU ld you will use a linker control file, too.

Something like this:

...
. = ALIGN(4 * 1024);
.nocacheram	:
{
	*(.nocacheram)
}
. = ALIGN(4 * 1024);
...

>        This would align ".nocacheram" on a 4kb boundary, and would
>       ensure 4Kb length as well (since the following group was also
>       4Kb aligned).

Same here.

> 3.  Once I have defined, declared, and aligned these special memory
>     regions, how would I determine their base/length?  Again, under
>     GreenHills, we would declare:
>
>       extern char __ghsbegin_nocacheram[];
>       extern char __ghsend_nocacheram[];
>
>      Which would provide the 'begin' and 'end' address of the region,
>     allowing us to set the appropriate MMU attributes for this user-
>     defined area.

You can define symbols in the linker script, too. Like this:

...
. = ALIGN(4 * 1024);
begin_nocacheram	:
{
	*(.nocacheram)
}
end_nocacheram:
. = ALIGN(4 * 1024);
...

> 4.  I know the question of embedded libc comes up often.  For
>     the most part, we basically need the 'strxxx' and 'memxxx'
>     functions, but 'sprintf' is quite a different critter.  Since
>     we are running an 860, we won't have FP support (and we don't
>     want to deal with emulation).  Do most folks use a hand-patched
>     'sprintf' source file, manually removing the floating-point ops?
>     I've looked into this a few years ago (the gcc sprintf source
>     file is a horror).  Has the 'ulibc' that i've heard about been
>     used with success by anybody on this list for embedded non-linux
>     projects?

Again, have a look at U-Boot and Linux. (U-Boot reuses the Linux code.)

> 5.  We have access to many Macraigor 'Raven' BDM interfaces.  I've
>     downloaded the x86 Linux support tools for this device.  Has
>     anybody had good results with this device and support tools
>     under Linux?

We prrefer the BDI2000.

> 6.  OK, please don't flame me on this stupid question.  Does 'as'
>     (the assembler) run its source input through the 'cpp' C
>     PreProcessor?  I can always pipe through cpp myself with an
>     implicit 'make' target if I need to...

"as" does not use "cpp". If you want  to  use  "cpp",  then  you  can
either  use "cpp" in a separate step, or use "gcc" which knows how to
deal with "*.S" source files.

Again, see Linux and U-Boot code for examples.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If I can have honesty, it's easier to overlook mistakes.
	-- Kirk, "Space Seed", stardate 3141.9

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: embedded gcc PPC toolchain questions

[Ron Flory]

Jerry Van Baren wrote:
> As a piece of very important trivia, note that Wolfgang's example
> initialized the variable in the declaration.  If you don't initialize the
> variable, it won't end up in the desired section.  Yes, that is in the gcc
> manuals, just easy to miss :-).

  Thanks- I've been surprised by this cute little 'feature' on other
compilers.  Discovering it the hard way was a 'fun' way to blow a
day or two.  ;)

>
> References:
> http://sunsite.ualberta.ca/Documentation/Gnu/
> http://sunsite.ualberta.ca/Documentation/Gnu/gcc-3.0.2/html_node/gcc_100.html#SEC100

  The refs are most useful.  I was unaware that such low-level details of
gcc and friends had finally been documented, previous searches (a few years
ago) had turned up nada- or maybe i just didn't try hard enough...

thanks to all.


P.S.  Looking through past postings, are gcc 2.95.3 and binutils-2.10.1
       still the recommended versions for embedded use?  Has confidence
       in more modern versions been established yet?  I'll choose
       reliability over optimization every time, but i've heard of subtle
       issues with 2.95.3 as well.

ron


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: embedded gcc PPC toolchain questions

[Wolfgang Denk]

In message <3ED657D0.4070200@adtran.com> you wrote:
>
> Jerry Van Baren wrote:
> > As a piece of very important trivia, note that Wolfgang's example
> > initialized the variable in the declaration.  If you don't initialize the
> > variable, it won't end up in the desired section.  Yes, that is in the gcc
> > manuals, just easy to miss :-).
>
>   Thanks- I've been surprised by this cute little 'feature' on other
> compilers.  Discovering it the hard way was a 'fun' way to blow a
> day or two.  ;)

Actually it should be no big surprise. I  think  every  (?)  standard
conforming  C  compiler  will  put  uninitialized  data  into the BSS
segment (usually .bss in the linker scripts).

> P.S.  Looking through past postings, are gcc 2.95.3 and binutils-2.10.1
>        still the recommended versions for embedded use?  Has confidence
>        in more modern versions been established yet?  I'll choose
>        reliability over optimization every time, but i've heard of subtle
>        issues with 2.95.3 as well.

We used 2.95.3 a long time for the ELDK, now we use 2.95.4.

No problems were reported (yet).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There's no sense in being precise  when  you  don't  even  know  what
you're talking about.                             -- John von Neumann

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: embedded gcc PPC toolchain questions

[Wolfgang Denk]

In message <F0B628F30F48064289D8CCC1EE21B7A80C4884@mvebe001.americas.nokia.com> you wrote:
> > Actually it should be no big surprise. I  think  every  (?)  standard
> > conforming  C  compiler  will  put  uninitialized  data  into the BSS
> > segment (usually .bss in the linker scripts).
>
> Is BSS, or sections, a part of the C standard?  Lots of data ends
> up in .sbss.

No. The C standard does not mention BSS or other linker sections. But
it contains requirements that may  be  (and  often  are)  implemented
using such sections, for example:

        All objects with static storage duration shall be initialized
        (set to their initial values) before program startup.

in detail:

	6.2.4 Storage durations of objects
	...
        3 An object whose identifier is declared with external or
          internal linkage, or with the storage-class specifier
          static has static storage duration. Its lifetime is the
          entire execution of the program and its stored value is
          initialized only once, prior to program startup.
	...
        ... If an object that has static storage duration is not
        initialized explicitly, then:
	- if it has pointer type, it is initialized to a null pointer;
        - if it has arithmetic type, it is initialized to (positive
          or unsigned) zero;
        - if it is an aggregate, every member is initialized
          (recursively) according to these rules;
        - if it is a union, the first named member is initialized
          (recursively) according to these rules.
	...

One method to implement this is to put uninitialized (or better:  not
explicitly initialized) static data into a BSS segment, which will be
cleared (set to zero) befor estarting the program.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Remember that Beethoven wrote his first symphony in C ...

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: embedded gcc PPC toolchain questions

[Erik Christiansen]

in message <3ED6298C.3070901@adtran.com> Ron Flory wrote:

> 4.  I know the question of embedded libc comes up often.  For
>     the most part, we basically need the 'strxxx' and 'memxxx'
>     functions, but 'sprintf' is quite a different critter.  Since
>     we are running an 860, we won't have FP support (and we don't
>     want to deal with emulation).  Do most folks use a hand-patched
>     'sprintf' source file, manually removing the floating-point ops?
>     I've looked into this a few years ago (the gcc sprintf source
>     file is a horror).  Has the 'ulibc' that i've heard about been
>     used with success by anybody on this list for embedded non-linux
>     projects?

Ron,

   We're happily using newlib's sprintf on the mpc850, in a piece of
   seriously embedded non-linux equipment.

   According to my rough notes, µClibc is LGPL, so static linking may not
   be a good idea. Newlib's BSD-like terms seemed more appealing to me.

   http://sources.redhat.com/newlib

   Bill Gatliff wrote an article on it, in the December 2001 issue of
   Embedded Systems Programming.

   There's apparently also dietlibc and sglibc, but I haven't
   investigated either.

Regards,
Erik


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/