This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Enabling DCACHE on GRG question. (RedBoot)


Lars, Sumanth (and list)
My JTAG debugger performs an initialization of the XScale registers
(similar the one in _platform_setup1) before it starts running the
RedBoot code.
I had to make the following additional changes:

1 - In ixp425_misc.c I commented out the line that enables the DCACHE:
HAL_DCACHE_ENABLE().
2 - In grg_pci.c hal_plf_pci_init() - I commented out 
"#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM)" 
so that PCI will be initialized even when loading a RAM image.

The above steps were enough to run the RAM image with my JTAG debugger
(vision ICE II).

To actually debug the code from startup I had to add debug symbols to
vectors.o (Added -Wa,-gstabs to the vectors.o target in the
arm\arch\current\makefile).
I also removed the O2 optimization level from some of the make files.

I still do not understand why did I have to comment out the
HAL_DCACHE_ENABLE(). If somebody can explain this it wil be nice.

Shmuel

P.S - vectors.o is never erased, even when doing clean all. I think it
is a bug in the ecos makefiles.



-----Original Message-----
From: Lars Povlsen [mailto:lpovlsen@vitesse.com] 
Sent: Thursday, March 02, 2006 3:13 PM
To: Shmuel Vagner
Cc: eCos Disuss
Subject: 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

 
 
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]