This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: PID ROM and eCos
- To: "Jonathan Larmour" <jlarmour at redhat dot com>
- Subject: Re: [ECOS] PID ROM and eCos
- From: "Dave Airlie" <airlied at parthus dot com>
- Date: 25 Jan 2001 17:56:28 +0000
- Cc: "Gary Thomas" <gthomas at redhat dot com>, ecos-discuss at sources dot redhat dot com, "Grant Edwards" <grante at visi dot com>
> Firstly, it should be down to the user on whether they want to copy to RAM.
> But also I've done other work (Gary can probably guess what) this way and
> it was no real trouble. The only problem is determining real addresses
> before relocation, but that's easy too. With the ARM you could even use MMU
> tricks, but I wouldn't recommend it :).
I'm hitting a small snag which may not be a snag but is catching me none
the less,
The PID flash programmer seems to use a trick to get the image for the
FLASH into memory, after generating the ROM image up at 0x4000000, objcopy
is used to relocate it down to 0x60000, and this loaded to the PID via
angel, the flash programmer is then downloaded and executed at 0x8000, and
it writes the stuff between 0x60000 and 0x80000 into the FLASH at
0x4000000
This seems to be working okay for the ROM image, but not for me, I
relocate my image from 0x8000 to 0x60000, program it in and the first
thing I do in reset_vector after the RAM enable is copy it down to 0x8000,
Now I've just realised I'm not then jumping down to the code in RAM, but I
can't see where the other code does this, from the edbxxxx stuff..
Dave.
--
David Airlie, Software Engineer, Parthus Technologies plc.,
Mary Rosse Centre, National Tech Park, Limerick, Ireland.
t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com