Re: redboot does not start in ram mode

[Gary Thomas <gary at mlbassoc dot com>]

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
  RedBoot> go

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 <gary@mlbassoc.com>
MLB Associates