posting back to maillits - removed the attachment.
---------- Forwarded message ---------- From: mukund jampala <[email protected]> Date: Sat, Jul 11, 2009 at 4:51 PM Subject: Re: [ECOS] Need uncached memory for USB - Redboot IXP435 To: Stanislav Meduna <[email protected]> Cc: eCos Discussion <[email protected]> Thanks stanislav for your help. On 7/11/09, Stanislav Meduna <[email protected]> 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
