* [ECOS] Need uncached memory for USB - Redboot IXP435 @ 2009-07-11 7:29 mukund jampala 2009-07-11 7:53 ` Stanislav Meduna 0 siblings, 1 reply; 4+ messages in thread From: mukund jampala @ 2009-07-11 7:29 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Need uncached memory for USB - Redboot IXP435 2009-07-11 7:29 [ECOS] Need uncached memory for USB - Redboot IXP435 mukund jampala @ 2009-07-11 7:53 ` Stanislav Meduna [not found] ` <cded4b0e0907111651t6bdcd749w274dceb2adca3f4b@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Stanislav Meduna @ 2009-07-11 7:53 UTC (permalink / raw) To: eCos Discussion 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <cded4b0e0907111651t6bdcd749w274dceb2adca3f4b@mail.gmail.com>]
* [ECOS] Fwd: [ECOS] Need uncached memory for USB - Redboot IXP435 [not found] ` <cded4b0e0907111651t6bdcd749w274dceb2adca3f4b@mail.gmail.com> @ 2009-07-12 6:28 ` mukund jampala 2009-07-12 7:34 ` [ECOS] " Stanislav Meduna 0 siblings, 1 reply; 4+ messages in thread From: mukund jampala @ 2009-07-12 6:28 UTC (permalink / raw) To: eCos Discussion 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: Need uncached memory for USB - Redboot IXP435 2009-07-12 6:28 ` [ECOS] Fwd: " mukund jampala @ 2009-07-12 7:34 ` Stanislav Meduna 0 siblings, 0 replies; 4+ messages in thread From: Stanislav Meduna @ 2009-07-12 7:34 UTC (permalink / raw) To: eCos Discussion 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-07-12 7:34 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-11 7:29 [ECOS] Need uncached memory for USB - Redboot IXP435 mukund jampala 2009-07-11 7:53 ` Stanislav Meduna [not found] ` <cded4b0e0907111651t6bdcd749w274dceb2adca3f4b@mail.gmail.com> 2009-07-12 6:28 ` [ECOS] Fwd: " mukund jampala 2009-07-12 7:34 ` [ECOS] " Stanislav Meduna
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).