strucking up in infinite loop for IXP 425

[sumanth]

Hi,

              we are porting  ecos for ixp425 we have flashed the image as per the sugessition in the forum but we are running in the infinite loop at this point

icache_boundary:
        // Here is where we switch from boot address (0x000000000) to the
        // actual flash runtime address. We align to cache boundary so we
        // execute from cache during the switchover. Cachelines are 8 words.
        str     r1, [r2, #IXP425_EXP_CNFG0]    // make the EXP bus switch
        nop
        nop
        nop
        nop
   ----> mov     pc, r0
        nop

  where the instruction says pc value to load into r0 is at the same location and it goes into infinite loop and never stops execution
 
                                  if i change the pc to ignore the step mov pc,r0 then the code is allowing single stepping but the instruction is not getting effected
 
can any one help out to sort this problem.


thanks & regards,
Sumanth

[Andrew Lunn-2]

On Tue, Feb 28, 2006 at 02:15:38AM -0800, sumanth wrote:

>
> Hi,
>
>               we are porting  ecos for ixp425 we have flashed the image as
> per the sugessition in the forum but we are running in the infinite loop at
> this point
>
> icache_boundary:
>         // Here is where we switch from boot address (0x000000000) to the
>         // actual flash runtime address. We align to cache boundary so we
>         // execute from cache during the switchover. Cachelines are 8 words.
>         str     r1, [r2, #IXP425_EXP_CNFG0]    // make the EXP bus switch
>         nop
>         nop
>         nop
>         nop
>    ----> mov     pc, r0
>         nop
>
>   where the instruction says pc value to load into r0 is at the same
> location and it goes into infinite loop and never stops execution
>  
>                                   if i change the pc to ignore the step mov
> pc,r0 then the code is allowing single stepping but the instruction is not
> getting effected
>  
> can any one help out to sort this problem.

You probably have your memory map wrong in the linker file .mlt.  What
address are you linking the image to run at.

        Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[sumanth]

Hi Andrew

           thanks for your help Andrew

           I have changed the address from 20000 to 0 location as given
in
           manual as per your sugessition in .mlt and .ldi files with
this
           I am able to continue upto cyg_hal_plf_pci_init , I am
strucking
           at pci , I am strucked up at this call

           HAL_PCI_CFG_WRITE_UINT32(0, 0, CYG_PCI_CFG_BAR_1,
0x01000000);
 
           are there any pointers at this situation that can help me

Thanks & regards,
Sumanth.


-----Original Message-----
From: Andrew Lunn [mailto:andrew@...]
Sent: Tuesday, February 28, 2006 4:35 PM
To: Sumanth Kumar Kondlada (WT01 - Product Engineering Solutions)
Cc: ecos-discuss@...
Subject: Re: [ECOS] strucking up in infinite loop for IXP 425

On Tue, Feb 28, 2006 at 02:15:38AM -0800, sumanth wrote:
>
> Hi,
>
>               we are porting  ecos for ixp425 we have flashed the
> image as per the sugessition in the forum but we are running in the
> infinite loop at this point
>
> icache_boundary:
>         // Here is where we switch from boot address (0x000000000) to
the
>         // actual flash runtime address. We align to cache boundary so
we
>         // execute from cache during the switchover. Cachelines are 8
words.
>         str     r1, [r2, #IXP425_EXP_CNFG0]    // make the EXP bus
switch

>         nop
>         nop
>         nop
>         nop
>    ----> mov     pc, r0
>         nop
>
>   where the instruction says pc value to load into r0 is at the same
> location and it goes into infinite loop and never stops execution
>  
>                                   if i change the pc to ignore the
> step mov pc,r0 then the code is allowing single stepping but the
> instruction is not getting effected
>  
> can any one help out to sort this problem.

You probably have your memory map wrong in the linker file .mlt.  What
address are you linking the image to run at.

        Andrew


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[Andrew Lunn-2]

On Fri, Mar 03, 2006 at 10:22:21AM +0530, sumanth.kondlada@... wrote:
>
>

> Hi Andrew
>
>            thanks for your help Andrew
>
>            I have changed the address from 20000 to 0 location as given
> in
>            manual as per your sugessition in .mlt and .ldi files with
> this
>            I am able to continue upto cyg_hal_plf_pci_init , I am
> strucking

>            at pci , I am strucked up at this call

>
>            HAL_PCI_CFG_WRITE_UINT32(0, 0, CYG_PCI_CFG_BAR_1,
> 0x01000000);
>  

>            are there any pointers at this situation that can help me

Actually, this is not what i said. All i did was ask the question
where it was linked to run at.

You see that often the FLASH is mapped to 0x0 at boot time. Early in
the boot sequence this mapping is changed. The FLASH is put into high
memory and RAM is put at 0x0. You program looked to be looping at the
point that it jumped from the low address in flash to the high address
in flash. So you need to check a few things....

Is the memory map setup so that the image runs at its high address? It
should do. All the startup code before the jump will be position
independant and so can run at either address. After the jump the code
is position dependent and can only run at the address it was linked
to.

Before the jump what address was in the PC? Low or high? It should be
low.

When it tries to make the jump, does it try to jump to the low or the
high address? It should be high.

Is the high address actually correct for the hardware? Just before the
jump take a look at the contents of the memory at the high address and
make sure it does contain the code.

        Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[sumanth]

Hi Andrew,

I am now trying with default ram image except for the rom_vectors in
.mlt and .ldi which have been remapped from 20000 to 0x00.
This am running without the redboot on the board and hence no
platform_setup is being done when I start.
On power on am forced to program the expansion bus registers and refresh
Cycles of sdram as the debugger + ice will not allow me to download the
image otherwise. Thus the SDRAM programming part is taken care of.
And the Cache enabling is done as part of hal_hardware_init in default
ram image.
Guess only section of platform_setup that I am missing is mmu tables
setup.
Just copying this code in reset_vector may not work as the tables are
being Built in location 0x4000. Any help in how to proceed in this...
Also, it is in this context that I had written my previous mail on how
the execution is able to proceed till HAL_PCI_CFG_WRITE_UINT32.
This is a crude hack, but without a flasher yet in my hand, me thinks
this is best option availible. Any advice on how to proceed...

Thanks & regards,
Sumanth.

-----Original Message-----
From: Andrew Lunn [mailto:andrew@...]
Sent: Friday, March 03, 2006 2:26 PM
To: Sumanth Kumar Kondlada (WT01 - Product Engineering Solutions)
Cc: ecos-discuss@...
Subject: Re: [ECOS] strucking up in infinite loop for IXP 425

On Fri, Mar 03, 2006 at 10:22:21AM +0530, sumanth.kondlada@...
wrote:

>
>
> Hi Andrew
>
>            thanks for your help Andrew
>
>            I have changed the address from 20000 to 0 location as
> given in
>            manual as per your sugessition in .mlt and .ldi files with
> this
>            I am able to continue upto cyg_hal_plf_pci_init , I am
> strucking
>            at pci , I am strucked up at this call
>
>            HAL_PCI_CFG_WRITE_UINT32(0, 0, CYG_PCI_CFG_BAR_1,
> 0x01000000);
>  
>            are there any pointers at this situation that can help me

Actually, this is not what i said. All i did was ask the question where
it was linked to run at.

You see that often the FLASH is mapped to 0x0 at boot time. Early in the
boot sequence this mapping is changed. The FLASH is put into high memory
and RAM is put at 0x0. You program looked to be looping at the point
that it jumped from the low address in flash to the high address in
flash. So you need to check a few things....

Is the memory map setup so that the image runs at its high address? It
should do. All the startup code before the jump will be position
independant and so can run at either address. After the jump the code is
position dependent and can only run at the address it was linked to.

Before the jump what address was in the PC? Low or high? It should be
low.

When it tries to make the jump, does it try to jump to the low or the
high address? It should be high.

Is the high address actually correct for the hardware? Just before the
jump take a look at the contents of the memory at the high address and
make sure it does contain the code.

        Andrew


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss