redboot does not start in ram mode

redboot does not start in ram mode

[Martin Laabs]

Hi,

I have a  3e-524 board with an IXP425. Because I want
to update the redboot I tried to compile a ram version.
Therefor I used the guide from intel beacuse the board seems
to be only slightly different from intels IXDP425 board.
I changed the memory map and tried to load/start the image. I failed.
After many attempt I tried to load the original RAM version that
is saved in the flash:

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0x51000000  0x51000000  0x00040000  0x00000000
RedBoot config    0x517C0000  0x517C0000  0x00001000  0x00000000
FIS directory     0x517E0000  0x517E0000  0x00020000  0x00000000
RedBoot_RAM       0x51040000  0x11400000  0x00040000  0x00000000
zImage            0x51080000  0x11400000  0x000C0000  0x00000000
RedBoot> fis load RedBoot_RAM
RedBoot> go

But after pressing return the board hangs. Because there is an eeprom
onboard the RAM begins at 0x10000000

edBoot> v 
RedBoot(tm) bootstrap and debug environment [ROM] 
Non-certified release, version 2.00 - built 10:04:47, Dec 17 2003 
 
Platform: 3eTI-EAP (XScale) 
Copyright (C) 2000, 2001, 2002, Red Hat, Inc. 
 
RAM: 0x10000000-0x12000000, 0x10115778-0x11fdd000 available 
FLASH: 0x51000000 - 0x51800000, 64 blocks of 0x00020000 bytes each. 


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.


In my own version I changed only the following in the .ldi file:

MEMORY
{
    ram : ORIGIN = 0x10200000, LENGTH = 0x10000000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (ram, 0x10200020, LMA_EQ_VMA)
    SECTION_rom_vectors (ram, 0x10220000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
[...] (rest unchanged)

and of cause CYGMEM_REGION_ram in the coresponding header file.

Do you have a hint how to start the RAM image from the flash
or my own compiled image? Or maybe you can tell me how to
debug it without JTAG.

Thank you
 Martin Laabs

Re: redboot does not start in ram mode

[Andrew Lunn]

On Thu, Jul 08, 2004 at 10:54:55PM +0200, Martin Laabs wrote:
> Hi,
> 
> I have a  3e-524 board with an IXP425. Because I want
> to update the redboot I tried to compile a ram version.
> Therefor I used the guide from intel beacuse the board seems
> to be only slightly different from intels IXDP425 board.
> I changed the memory map and tried to load/start the image. I failed.
> After many attempt I tried to load the original RAM version that
> is saved in the flash:
> 
> RedBoot> fis list
> Name              FLASH addr  Mem addr    Length      Entry point
> RedBoot           0x51000000  0x51000000  0x00040000  0x00000000
> RedBoot config    0x517C0000  0x517C0000  0x00001000  0x00000000
> FIS directory     0x517E0000  0x517E0000  0x00020000  0x00000000
> RedBoot_RAM       0x51040000  0x11400000  0x00040000  0x00000000
> zImage            0x51080000  0x11400000  0x000C0000  0x00000000
> RedBoot> fis load RedBoot_RAM
> RedBoot> go
> 
> But after pressing return the board hangs. Because there is an eeprom
> onboard the RAM begins at 0x10000000
> 
> edBoot> v 
> RedBoot(tm) bootstrap and debug environment [ROM] 
> Non-certified release, version 2.00 - built 10:04:47, Dec 17 2003 
>  
> Platform: 3eTI-EAP (XScale) 
> Copyright (C) 2000, 2001, 2002, Red Hat, Inc. 
>  
> RAM: 0x10000000-0x12000000, 0x10115778-0x11fdd000 available 
> FLASH: 0x51000000 - 0x51800000, 64 blocks of 0x00020000 bytes each. 
> 
> 
> 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.

> In my own version I changed only the following in the .ldi file:
> 
> MEMORY
> {
>     ram : ORIGIN = 0x10200000, LENGTH = 0x10000000
> }
> 
> SECTIONS
> {
>     SECTIONS_BEGIN
>     SECTION_fixed_vectors (ram, 0x10200020, LMA_EQ_VMA)
>     SECTION_rom_vectors (ram, 0x10220000, LMA_EQ_VMA)
>     SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
> [...] (rest unchanged)
> 
> and of cause CYGMEM_REGION_ram in the coresponding header file.


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...

        Andrew

Re: redboot does not start in ram mode

[Martin Laabs]

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?

Thank you 
 Martin Laabs

Re: redboot does not start in ram mode

[Gary Thomas]

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

"fis create" substitute

[Edgar Grimberg]

It's me again with FS problems. 

Is there any way to substitute the "fis create" command in RedBoot with
some other means to load an image to the flash? (I have an BDI2000
debugger). I need this because of insufficient RAM on my board, so I
have no room to store an image in RAM. I want to flash some JFFS2 image
and run the jffs test application.

Thanks,
Edgar

Re: redboot does not start in ram mode

[David Vrabel]

Martin Laabs wrote:
> 
> I have a  3e-524 board with an IXP425... Because there is an eeprom
> onboard the RAM begins at 0x10000000

This doesn't make any sense. On an IXP425 0x10000000 is a alias for 
0x00000000.

I'd suggest looking up where the eeprom really is.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/