public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gthomas@cygnus.co.uk>
To: Nicholas_Clarey@ivesco.co.uk
Cc: ecos-discuss@sourceware.cygnus.com
Subject: RE: [ECOS] Building rommable images for the AEB-1C
Date: Thu, 06 Jan 2000 05:00:00 -0000	[thread overview]
Message-ID: <XFMail.000106060020.gthomas@cygnus.co.uk> (raw)
In-Reply-To: <OFC98C1471.F607250D-ON8025685E.00462FB5@ivesco.co.uk>

On 06-Jan-00 Nicholas_Clarey@ivesco.co.uk wrote:
> Howdy all,
> 
> I've been trying to create an image that I can put into the Arm Evaluation 
> 
> Board flash rom so that I can take over the serial port and play with it. 
> Unfortunately, it's not working.
> 
> I have managed the first stage of producing the CVS gdb stubs and flashed 
> them successfully, and have written test programs, downloaded them and 
> played with them fine. I followed all the necessary instructions in the 
> documentation to do this.
> 
> Here's what I've done so far;
> 
> - produced the build directory with the following command;
> 
> tclsh BASE_DIR/packages/pkgconf.tcl --target=arm 
> --platform=aebC--startup=rom
> 
> which I figured would do what was necessary to give me libraries and stuff 
> 
> I could link with and place in ROM rather than RAM.
> 
> - edited the pkgconf/serial_io.h header file to enable the serial port(s) 
> by #defining the aeb serial port stuff
> - run "make"
> - wrote a simple c program that opened the serial port and dumped some 
> trivial data to it
> 
> When I try to compile the c program in the last step, I did the following;
> 
> arm-elf-gcc -Iinstall/include testfile.c -Linstall/lib -Ttarget.ld 
> -nostdlib
> 
> and I get two errors and two warnings;
> 
> testfile.c: In function `cyg_user_start':
> testfile.c:32: warning: passing arg 4 of `cyg_io_set_config' makes pointer 
> 
> from integer without a cast
> testfile.c:37: warning: passing arg 3 of `cyg_io_write' makes pointer from 
> 
> integer without a cast

I'd have to see your sources to know exactly why you get these warnings.
However, they are from the compiler, telling you that you are apparently not
passing the correct "type" of information to the cyg_io_XXX() functions.

The severity of such missuse can range from being totally benign to complete
failure.  In particular, the second warning says that you've passed an integer
and not a pointer as the third parameter to 'cyg_io_write()'.  This parameter
must be a pointer to the length, not the length itself.  This is because the
function returns the actual number of bytes written in the variable, in case
it differed for some reason from the requested number.

> /usr/cygnus/ecosSWtools-arm-990321/i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.9 
> 
> -ecosSWtools-arm-990321/../../../../arm-elf/bin/ld: address 0x40219ac of 
> a.out section .text is not within region rom
> /usr/cygnus/ecosSWtools-arm-990321/i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.9 
> 
> -ecosSWtools-arm-990321/../../../../arm-elf/bin/ld: address 0x4021c34 of 
> a.out section .rodata is not within region rom

If you look at the ROM layout, you'll see that it is only set up to handle
small programs in the flash/ROM.  The default setup is for 32K (0x8000) bytes
at the end of the flash.  The flash on that board is quite limited (128K) and
we didn't want to destroy what was already there (the boot loader, etc).

> /usr/cygnus/ecosSWtools-arm-990321/i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.9 
> 
> -ecosSWtools-arm-990321/../../../../arm-elf/bin/ld: warning: no memory 
> region specified for section `.glue_7'
> /usr/cygnus/ecosSWtools-arm-990321/i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.9 
> 
> -ecosSWtools-arm-990321/../../../../arm-elf/bin/ld: warning: no memory 
> region specified for section `.glue_7t'

I don't understand these warnings at all [yes, I know what they mean, I just
don't know how you created them].  

What compiler/toolset are you using?
Did you use any special compiler options when building the program?

The other thing to note about running programs in flash/ROM on the AEB is that
eCos assumes that the ARM bootloader is in place, even for these.  This means
that you'll need to set up a flash image "module" which follows the ARM rules.
This is a rather tricky process and not terribly simple to automate.  You
can look at ".../hal/arm/aeb/XXX/misc/PKGconf.mak" to see how it is done for
the GDB stubs.

  reply	other threads:[~2000-01-06  5:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-06  4:38 Nicholas_Clarey
2000-01-06  5:00 ` Gary Thomas [this message]
2000-01-06  6:50   ` Grant Edwards
2000-01-06  7:01     ` Gary Thomas
2000-01-06  7:03     ` Dan Hovang
2000-01-06  5:40 Nicholas_Clarey
     [not found] <OF3C6DA87D.CDC4B358-ON8025685E.004A10DF@ivesco.co.uk>
2000-01-06  6:45 ` Gary Thomas
     [not found] <OF7B928FC7.8F137C30-ON8025685E.005316F3@ivesco.co.uk>
2000-01-06  7:15 ` Gary Thomas
2000-01-07  6:46   ` Dan Hovang
2000-01-07  7:19     ` Gary Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=XFMail.000106060020.gthomas@cygnus.co.uk \
    --to=gthomas@cygnus.co.uk \
    --cc=Nicholas_Clarey@ivesco.co.uk \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).