[ECOS] Re: Enabling DCACHE on GRG question. (RedBoot)

sumanth.kondlada@wipro.com sumanth.kondlada@wipro.com
Fri Mar 3 04:32:00 GMT 2006


Hi Shmuel (and list)!

         I am also porting ecos for ixp425 eval board using grg with the
         
         help of Axd Debugger as you did but I am getting struck up at

         cyg_hal_plf_pci_init in this routine at

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

         As you said that you have already debugged the entire rom,ram

         versions so please help me how to make changes at this
situation

         You said that you took some effort , can you please help me how

         to proceed further and what the things to be taken care in this

   
         total debugging process.


Thanks & Regards
Sumanth
 



 It took some effort but finally I am able to debug the entire boot
> sequence.

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Lars
Povlsen
Sent: Thursday, March 02, 2006 6:43 PM
To: Shmuel.Vagner@celeno.com
Cc: eCos Disuss
Subject: [ECOS] Re: Enabling DCACHE on GRG question. (RedBoot)


On Mon, 13 Feb 2006 02:39:14 +0200, Shmuel Vagner wrote:
> HI,
> I am running RedBoot on a GRG platform.
> I was able to compile and run both ROM and RAM versions.
> Next I tried to debug the RAM version from startup using a JTAG
debugger
> (Vison ICE II).
> It took some effort but finally I am able to debug the entire boot
> sequence.
>
> There is only one thing that I could not get to work:
> In ixp425_misc.c hal_hardware_init() the line: HAL_DCACHE_ENABLE()
> crashes so I had to comment it out.
> I browsed through the Archives and found out that the problem is that
> the MMU is not initialized in the RAM version (It assumes that the ROM

> already did it).
> Now, the code that is responsible for MMU initializations is in
> hal_platform_setup.h _platform_setup1. The problem is that it includes
a
> lot more then MMU initialization and when I invoke it on startup the
> system crashes (Probably because it includes SDRAM initialization that

> was already done by the JTAG debugger).
>
> My question is what part from _platform_setup1 should I keep in the
RAM
> version in order to be able to work with data caches.
> Thanks
> Shmuel
<

Hi Shmuel (and list)!

I noticed your message on the ecos-discuss archive list while searching
for a solution to the same problem.

Did you get any replies (didn't find any on the archive)?

Anycase, I noticed a small notice about a scenario of how to overcome
such an issue on
http://www.ecoscentric.com/ecospro/doc/html/ecospro-ref/arm-vpb926ejs-se
tup.html and
http://www.ecoscentric.com/ecospro/doc/html/ecospro-ref/arm-vpb926ejs-co
nfig.html - they produce a ROM kinda image and load it in the SRAM (with
a JTAG). With that way you can implement the "ROM" environment, but
don't have to flash for each update. Nifty.

Of course, this depends on whether your rig has "extra" memory like
this.

Did you get other suggestions, or did you solve this yourself?

Also using a "RAM" redboot setup I was doing a board bringup and getting
fried by the missing MMU initalization. I thought I'ld just add the
CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP = 0 option to my redboot_RAM - but
no! The HAL_ICACHE_ENABLE macro in
hal/arm/arm9/var/current/include/hal_cache.h *insists* on enabling the
MMU as well. So I bomb out the same, unless I disable the ICACHE also
(or change the code)...

Does anyone have an explanation as to why HAL_ICACHE_ENABLE enables the
MMU? I know that HAL_DCACHE_ENABLE should do so, but I regard the latter
as an error, or am I missing something here?

---Lars

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



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



More information about the Ecos-discuss mailing list