RE: [ECOS] strucking up in infinite loop for IXP 425

[<sumanth dot kondlada at wipro dot com>]

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@lunn.ch]
Sent: Friday, March 03, 2006 2:26 PM
To: Sumanth Kumar Kondlada (WT01 - Product Engineering Solutions)
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] strucking up in infinite loop for IXP 425

On Fri, Mar 03, 2006 at 10:22:21AM +0530, sumanth.kondlada@wipro.com
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