[ECOS] Fwd: [ECOS] Need uncached memory for USB - Redboot IXP435

[mukund jampala]

posting back to maillits - removed the attachment.


---------- Forwarded message ----------
From: mukund jampala <mukund.redboot@gmail.com>
Date: Sat, Jul 11, 2009 at 4:51 PM
Subject: Re: [ECOS] Need uncached memory for USB - Redboot IXP435
To: Stanislav Meduna <stano@meduna.org>
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>


Thanks stanislav for your help.

On 7/11/09, Stanislav Meduna <stano@meduna.org> wrote:
> mukund jampala wrote:
>
>> So, I resolved to start using the flush/invalidate MACROS.
>> HAL_DCACHE_FLUSH / HAL_DCACHE_INVALIDATE.
>> But it does not work some how? Strangely, it does not flush the
>> buffers completely.
>
> Are the cache sizes set properly in the HAL configuration?
I don't know if this what you are talking about.
file: hal/arm/xscale/cores/current/include/hal_cache.h

#define HAL_DCACHE_SIZE                 0x8000 // Size of data cache in bytes
#define HAL_DCACHE_LINE_SIZE            32     // Size of a data cache line
#define HAL_DCACHE_WAYS                 32     // Associativity of the cache
#define HAL_DCACHE_SETS (HAL_DCACHE_SIZE/(HAL_DCACHE_LINE_SIZE*HAL_DCACHE_WAYS))

#define HAL_ICACHE_SIZE                 0x8000 // Size of icache in bytes
#define HAL_ICACHE_LINE_SIZE            32     // Size of ins cache line
#define HAL_ICACHE_WAYS                 32     // Associativity of the cache
#define HAL_ICACHE_SETS (HAL_ICACHE_SIZE/(HAL_ICACHE_LINE_SIZE*HAL_ICACHE_WAYS))

>
> I had a similar issue (gdb breakpoints not seen by the processor)
> and the problem was that the ICACHE size was set to zero,
> causing the macros not to do anything.

Also, this may not be the problem too. Because IXP NPE drivers work
fine which are in the same code base. They use the same MACROS. i.e.
HAL_DCACHE_FLUSH ...

> Does anything change if you flush the whole cache and not
> only the address/size region? Maybe the macros are flawed somehow.

Exactly, it does work if I flush the whole cache away with following code:
file: hal/arm/xscale/ixp425/current/src/ixp425_misc.c
#if 1
   HAL_DISABLE_INTERRUPTS(oldints);
   HAL_DCACHE_SYNC();
   HAL_DCACHE_DISABLE();
   HAL_DCACHE_SYNC();
   HAL_DCACHE_INVALIDATE_ALL();
   HAL_RESTORE_INTERRUPTS(oldints);
#endif

But, once I disable this code part, and I flush individual buffers, I
loose the whole communication.

>
>> The same code works perfectly if I disable the CACHING by placing the
>> following code in hal_hardware_init(void).

> Another idea: are you 100% sure this is a cache issue?
> Disabling the caches also changes timings, sometimes
> dramatically.

Dude, I just got one thing.....
I disabled all my printf in my code and HC which was halting does not
hal anymore, whcih is a good sign. I have lots of printfs. if I enable
low DEBUG mode with less printfs, it works fine.
Is this a bus contention issue?

No ideans what the relation between this behaviou and caching??

Also, I have attached the hal folder by tarring it.

- Mukund Jampala

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

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