This is the mail archive of the
mailing list for the eCos project.
Re: redboot does not start in ram mode
On Fri, 2004-07-09 at 07:25, Martin Laabs wrote:
> On Fri, Jul 09, 2004 at 10:40:01AM +0200, Andrew Lunn wrote:
> > On Thu, Jul 08, 2004 at 10:54:55PM +0200, Martin Laabs wrote:
> > > But when I load the RedBoot_RAM to 0x10200000 (or an other
> > > explicit address with the -b option) I get much binary data
> > > printet onto my terminal.
> > eCos images are not position independant. So this will not work.
> Why isn't it? Does it depend on the interrupt vectors and so on?
> > You might want to take a look at the MMU setup. Normally the RAM is
> > mapped by the MMU to address 0. It could be that on your hardware it
> > is mapping the EEPROM to memory zero, which is not going to work...
> Yes. You are right. The Ram is mapped to 0x10000000-0x12000000.
> So I can't load redboot to 0x0:
> RedBoot> load -r -b 0 -m x
> Specified address (0x00000000) is not believed to be in RAM - are you sure (y/n
> This is exactly my problem. But the manufacturer placed a RAM
> version of redboot in the fis and this also does not work.
> I thought it is enough only to change the linker script and
> the constant in the header file.
> Can you give me a hint how to change redboot that it works
> at another adress than 0x0?
You should be able to just:
RedBoot> load -m xm
Note: I explicitly did *not* use:
-r - this option tells RedBoot to download binary data without any
interpretation of the format. If you are downloading an
executable, this option would cause incorrect results.
-b - Again, let the executable file itself tell RedBoot where to
load the data.
What does 'arm-elf-objdump -h <redboot.ELF>" show? (where <redboot.ELF>
is the name of the ELF image that you built)? This will show exactly
how the program has been linked and where it should be loaded.
Gary Thomas <firstname.lastname@example.org>