Re: [ECOS] "Hello, world" on AEB without gdb

Re: [ECOS] "Hello, world" on AEB without gdb

[k e]

Thanks for the replies.
I'd prefer to learn, first, how to compile, link, etc.
an AEB executable (without gdb info) for --> RAM <--.
So a couple of questions on how to build a simple
program for execution on the AEB without gdb and
loaded only into RAM:
- Will I still need to configure a kernel with the ROM
  option, or should I be able to use my RAM
  configuration that I've successfully used
  to build simple programs that DO run under gdb?
- Are there any special compiler options to "clean
  up" the code, or with the objcopy --strip-debug
  take care of all of the cleanup.
- Are there any special linker options that are
  required to ensure that the correct startup
  routines are loaded since gdb will not be helping
  out?
- Is there a need for the change-addresses function
  if I only want to execute from the default load
  point in RAM?

I've been able to build (using the RAM kernel) and
download what I thought was going to be an executable
that wouldn't need gdb to execute, but it didn't
work... I must still be missing something


If my description, above, isn't enough to go on,
I'll re-submit a note detailing the steps I've taken.

Thanks for you patience,
keith
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [ECOS] "Hello, world" on AEB without gdb

[Gary Thomas]

On 26-Jan-00 Jesper Skov wrote:
>>>>>> "k" == k e <ndgipper@yahoo.com> writes:
> 
> k> Jesper, Thanks for the hints.  I'll try them soon.  I can't,
> k> however, find any reference to --change-address=0xXXXXXXXX in the
> k> objcopy chapter in the GNUProtools documentation.  Can you describe
> k> what that option does and in particular what the significance of
> k> the 0xFBFF4000 address is.
> 
> k> Thanks for you patience.  keith
> 
> Oh. Nor can I. Binutils documentation bug, I reckon.
> 
> I'm pretty sure it just adjusts all the absolute addresses in the
> image by the specified offset.
> 
> That may be necessary if the eCos memory mapping differs from the
> default memory mapping of the firmware environment (i.e., the GDB stub
> would be built to run in an environment where memory is mapped at
> 0x8000 - by subtracting 0xFBFF4000 that ends up being 0x4004000 which
> I think is in the ROM region. But I can't find the docs for the board
> right now, so I could be quite wrong).
> 

The ROM image needs to be linked at 0x40018000 (the location in the ROM/FLASH
where the image will reside and be executed from).

The tools for programming the ROM need it to be loaded at some other location
(in RAM).  The 'objcopy' command with the change-addresses option does this.
It simply adjusts the ELF headers so that the image will be loaded somewhere,
without relinking it.  One can then use the normal tools to load this image
into RAM, and place it into ROM/FLASH.

... and yes, it is rather like magic :-)

Re: [ECOS] "Hello, world" on AEB without gdb

[Jesper Skov]

>>>>> "k" == k e <ndgipper@yahoo.com> writes:

k> Jesper, Thanks for the hints.  I'll try them soon.  I can't,
k> however, find any reference to --change-address=0xXXXXXXXX in the
k> objcopy chapter in the GNUProtools documentation.  Can you describe
k> what that option does and in particular what the significance of
k> the 0xFBFF4000 address is.

k> Thanks for you patience.  keith

Oh. Nor can I. Binutils documentation bug, I reckon.

I'm pretty sure it just adjusts all the absolute addresses in the
image by the specified offset.

That may be necessary if the eCos memory mapping differs from the
default memory mapping of the firmware environment (i.e., the GDB stub
would be built to run in an environment where memory is mapped at
0x8000 - by subtracting 0xFBFF4000 that ends up being 0x4004000 which
I think is in the ROM region. But I can't find the docs for the board
right now, so I could be quite wrong).


Jesper

Re: [ECOS] "Hello, world" on AEB without gdb

[Jesper Skov]

>Another, hopefully, simple newbie question:
>Can someone point me to an online document or explain
>briefly the steps involved in building a simple single
>thread routine for the AEB that does NOT require gdb
>to
>load and execute.  Am I correct in thinking that it
>involves using objcopy?  I'd like to get the simple
>"Hello, world" routine that is in the 'Getting Started
>with eCos' document to work outside of the debugger.
>Then watch it tell me 'hello'.
>I assume it will involve some or more than the
>following steps:
> - possibly, configure a kernel for non-gdb ARM AEB???
> - compile with some special options
> - link with some other options
> - maybe some sort of translation to ARM object code
> - then a translation to ASCII (UUENCODE)
> - then an interactive session with the AEB booter
>   that would involve loading and then execution
>Or, am I off in "left field"?

Sounds about right. The easy part is configuring, building and
linking. What yuo do is select ROM startup and build the application
as normal.

Then you'll need to convert the executable to binary using something
like this:
 % arm-elf-objcopy --change-addresses=0xFBFF4000 --strip-debug [in] [out]
 % arm-elf-objcopy -O binary [in] [out]

Conversion to ASCII:

 % uuencode [in] [in] | tr '`' ' ' > [out]


Now, I'm not really sure how to continue.  Probably you'll be able to
just download this to the target and jump to the start address from
the AEB monitor (using GO?!?).

Look at the arm/hal/current/misc/PKGConf.mak which goes through all
this and some more in order to make a module which can be stored in
FLASH by the AEB rom loader. You shouldn't need to do the checksum
stuff though, when just running the downloaded program once.


If you get this working, it would be nice if you would extend the
hal/arm/aeb/misc/Notes with details on how it is done.

Thanks,
Jesper

[ECOS] "Hello, world" on AEB without gdb

[k e]

Another, hopefully, simple newbie question:

Can someone point me to an online document or explain
briefly the steps involved in building a simple single
thread routine for the AEB that does NOT require gdb
to
load and execute.  Am I correct in thinking that it
involves using objcopy?  I'd like to get the simple
"Hello, world" routine that is in the 'Getting Started
with eCos' document to work outside of the debugger.
Then watch it tell me 'hello'.
I assume it will involve some or more than the
following steps:
 - possibly, configure a kernel for non-gdb ARM AEB???
 - compile with some special options
 - link with some other options
 - maybe some sort of translation to ARM object code
 - then a translation to ASCII (UUENCODE)
 - then an interactive session with the AEB booter
   that would involve loading and then execution
Or, am I off in "left field"?

Thanks,
keith
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com