[ECOS] Need uncached memory for USB - Redboot IXP435

[ECOS] Need uncached memory for USB - Redboot IXP435

[mukund jampala]

Hi Guys,

I am having problems finding the uncached buffers on Redboot on IXP435.
I need these buffers to setup HW descriptors for USB EHCI controller.

I found no means of getting an uncached buffer. Let me know if there is one?
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.
And the controller gets confused.

The same code works perfectly if I disable the CACHING by placing the
following code in hal_hardware_init(void).
file: "hal/arm/xscale/ixp425/current/src/ixp425_misc.c".

    HAL_DISABLE_INTERRUPTS(oldints);
    HAL_DCACHE_SYNC();
    // HAL_ICACHE_DISABLE();
    HAL_DCACHE_DISABLE();
    HAL_DCACHE_SYNC();
    // HAL_ICACHE_INVALIDATE_ALL();
    HAL_DCACHE_INVALIDATE_ALL();
    HAL_RESTORE_INTERRUPTS(oldints);

I have developed a complete USB EHCI Host stack /drivers for Redboot.
I am this close to completion and I am struck here.

Please help reslove this issue. Any clues would help.

- 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

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

[Stanislav Meduna]

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 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.

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

> 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.


-- 
                                    Stano

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

[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

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

[Stanislav Meduna]

mukund jampala wrote:

>> 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

OK, looks fine.

Apropos, when exactly does your controller use data from the
cached region of the memory? Normally the control and status
registers shouldn't be cached and the processor-controlled
DMA data access should take care of the caches in any sane
processor. Is the controller doing DMA on its own?

>> 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

This disables the cache alltogehter. Does the code work
if you add HAL_DCACHE_ENABLE (i.e. disable, sync
and enable again)?

On some hardware (I don't know xscale) there is also
a way to access the same memory region uncached - e.g.
the ARM processor I am using maps the same RAM from
0x20000000 and from 0x00000000 and the HAL enables
the cache only for the first one. This would be generally
the best way.

> 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?

Well, diag_printf needs time. Sometimes a lot of time (1 ms
for 10 characters written at 115200). Generally, don't do it
in the middle of a transaction with the hardware.

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

It can of course cause another cache lines to be accessed etc.

-- 
                                    Stano

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