This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: "Hello, world" on AEB without gdb
- To: Jesper Skov <jskov at redhat dot com>
- Subject: Re: [ECOS] "Hello, world" on AEB without gdb
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Thu, 27 Jan 2000 06:17:32 -0700 (MST)
- Cc: ecos-discuss at sourceware dot cygnus dot com, k e <ndgipper at yahoo dot com>
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 :-)