questions on DM6467
Hi All, Is it possible that I only use DM6467's DSP core for a PCI slave device? Thanks George ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: questions on DM6467
Hi If I am not mistaken, pci is under arm control Albert On 6/12/08, Gu George [EMAIL PROTECTED] wrote: Hi All, Is it possible that I only use DM6467's DSP core for a PCI slave device? Thanks George ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: About the cache issues of dm6446
6727 has ONLY L1P (i.e. there is no L1D and no L2). Its L1P is not configurable as SRAM. I'm not sure I understand your question about the single cache line. The cache always operates on cache lines, so yes, a single cache line can be a victim. How much does what take? From: Albert Burbea [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 4:22 PM To: Griffis, Brad Cc: Andre Gaschler; kashin Lin; davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi another question - is it possible to victimize a single cache line? How much does it take? Also, Brad, are your remarks valid on the 6727 floating point TI DSP? 10x On 6/11/08, Griffis, Brad [EMAIL PROTECTED] wrote: You're both looking at documents that do not apply to the DM6446. Please go to the DM6446 product folder for documents applicable to this device: http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html#technicald ocuments Kashin, the guide you are looking at applies to 64x cache, not 64x+ cache. The correct guide, as seen in the product folder above, is: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3tabId=4 09familyId=1302abstractName=spru862a Andre, there is not a CSL for DM6446 and so those CSL commands should not be used (they are written for 64x, not 64x+). DSP/BIOS has a set of APIs, BCACHE, that can be used for modifying the cache settings at run-time. These APIs are described in the BIOS documentation. You can find the BIOS documentation inside the individual BIOS releases. For example: bios_5_32_02/packages/ti/bios/doc To answer the original questions: 1) A new feature of the 64x+ cache is that L1 memory is also configurable as either SRAM or cache. The hardware defaults to 32KB L1P and 32KB L1D. However, your BIOS tcf file can override this. 2) The L2 defaults to all SRAM. However, this also can be overridden in the BIOS tcf file. When data buffers are stored in L1D or L2 you do not need to worry at all about cache coherence as that will be handled by the hardware. However, if your data is stored in external memory, then you must be more careful with coherence if the data is being accessed by more than one source (e.g. ARM, DSP, EDMA, etc.). Turning on the L2 cache is not enough for external memory to actually get cached. There are a set of registers called MAR (memory attribute register) where you must set the bit corresponding to a range of DDR in order for that range to be cacheable. Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Gaschler Sent: Wednesday, June 11, 2008 4:20 AM To: kashin Lin Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi, for enabling caches in run time have a look into http://focus.ti.com/lit/ug/spru401j/spru401j.pdf especially the CACHE section. If you want access CMEM/DSPLINK data for example (that should be in DDR 0x87 - 0x88 ) you simply #include csl_cache.h to your DSP code and write CACHE_enableCaching ( CACHE_EMIFA_CE07 ) ; // Cache CMEM/DSPLINK area that is at the end of DDR memory L2SRAM is cached by default, DDR is not (so you probably want to enable that in run time). -- Andre Subject: About the cache issues of dm6446 From: kashin Lin [EMAIL PROTECTED] Date: Wed, 11 Jun 2008 15:51:23 +0800 To: davinci-linux-open-source@linux.davincidsp.com To: davinci-linux-open-source@linux.davincidsp.com Hi, i have read the DSP two-level internal memory reference guide (spru610) DSP cache user guide (spru656) but still have some questions about the dm6446 DSP side's cache: 1. by reading these two guides, it seems that level-1 memory ( L1D, L1P) are always used as cache and level-2 can be configured as SRAM or cache. but i found that on the dm6446 memory map described in sprs283 and .tcf file when using DSP/BIOS, there is a memory region named L1D RAM ranged from 0x11f04000 ~ 0x11f0 and another named L1D RAM/cache ranged from 0x11f1 ~ 0x11f17fff. does it mean L1D can also be configured as RAM or cache? how? any restriction? 2. when using DSP/BIOS on dm6446, does it defaultly set all L2 memory as SRAM (64K) and L1D and L1P as caches? should i enable the caches in run-time? and what are the default cacheability setting of L2SRAM and DDR(external memory)? thanks in advance. best, kashin lin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list
RE: What's on the target board?
Hi, I am not sure what you are asking for here (the bit before the numbered questions) I also assume you have a DM6446 not a DM355? 1/ The demo files are not installed on the NFS root filesystem. If you want them they are on one of the CDs or if you have a DM6446 they are in the /dev/hda2 partition along with the 'recovery' files. 2/ You need to post the output from the console the output of 'printenv' from u-boot before anyone can assist here. If you have changed the kernel from default, a copy of the configuration file would also help. Regards Phil Q Phil Quiney, Senior Software Engineer Trinity Convergence Cambridge Business Park Cowley Road Cambridge CB4 0WZ, UK T: +44(0)1223-435536 F: +44(0)1223-435560 www.trinityconvergence.com http://www.trinityconvergence.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ?? Sent: 09 June 2008 15:19 To: davinci-linux-open-source@linux.davincidsp.com Subject: What's on the target board? Hi, Everyone ,Thank u for the help ! I have just get a new DVEVM board, and I'm a newbie in this area. Now I connect the board with my laptop, I use the Getting started guide,and go to 4.4.1now. it comes [EMAIL PROTECTED] IP addr:# but it's nothing under the root , when I use the command 'ls', nothing come out? then I add the guest to login, I can just find the share files on the target. Q: 1,how to find the files on the target, (when it run the demo standalone , I saw the demos) 2, After I boot from Flash using NFS file system, the LCDs is always black with two small white suqres(1cm*1cm) in two left corners.What happens?How to make the LCDs work? 上房老大买二手房，看实景照片，挑专业经纪人 http://popme.163.com/link/003982_0604_5405.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Motion jpeg demo on code engine 2.10 does not working
Hello , Here is description of the problem: We are using eInfochip DVPB board with DM6446 ans software: -Monta Vista Linux - Codec Engine 2.10 - DSPLINK 1.50 - DSP/BIOS 5.32.01 We have downloaded application report SPRAAH9A “Motion JPEG Demo on TMS320DM6446” from ti.com and corresponding source code. First of all we got dsp\jpegencdecCombo.x64P from sources. But after EngineOpen call, application generates next error: DSP-side configuration mismatch/failure 0 - success Positive value - DSP-side failure code. (Uint32) -1- DSP-side component was not initialized. DRV configuration status[0x] IPS configuration status[0x] POOL configuration status [0x] MPCS configuration status [0x] MPLIST configuration status [0x] MQT configuration status[0x] RINGIO configuration status [0x] Then we decided to assemble our server from codecs in the source package -- dsp\jpegdec and dsp\jpegenc. As result – after EngineOpen call we get errors that are logged in log2.txt (attached). Memory map was carefully verified. .cfg server file is also attached. -- Best regards, Agat-system mailto:[EMAIL PROTECTED]- start processing @0x00089153:[T:0x4000] OG - Global_atexit enter (fxn=0xf324) @0x000893ff:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008952a:[T:0x4000] OM - Memory_alloc return (0x4c198) @0x00089789:[T:0x4000] OG - Global_atexit enter (fxn=0x1f170) @0x000898f7:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x000899e9:[T:0x4000] OM - Memory_alloc return (0x4c1e8) @0x00089aaa:[T:0x4000] OG - Global_atexit enter (fxn=0x1bf58) @0x00089bce:[T:0x4000] OG - Global_atexit enter (fxn=0x2038c) @0x00089d41:[T:0x4000] ti.sdo.ce.osal.Sem - Sem_create count: 0 @0x00089e1b:[T:0x4000] OM - Memory_alloc Enter(0x14) @0x00089ee6:[T:0x4000] OM - Memory_alloc return (0x4c268) @0x00089fdc:[T:0x4000] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x4c268] @0x0008a0a8:[T:0x4000] ti.sdo.ce.osal.Sem - Sem_create count: 0 @0x0008a15d:[T:0x4000] OM - Memory_alloc Enter(0x14) @0x0008a221:[T:0x4000] OM - Memory_alloc return (0x4c280) @0x0008a2ea:[T:0x4000] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x4c280] @0x0008a3d8:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008a4ba:[T:0x4000] OM - Memory_alloc return (0x4c298) @0x0008a57d:[T:0x4000] OT - Thread_create Enter (fxn=0x1b8ac, attrs=0x0) @0x0008a63d:[T:0x4000] OM - Memory_alloc Enter(0x64) @0x0008a714:[T:0x4000] OM - Memory_alloc return (0x4c2b8) @0x0008adeb:[T:0x4000] OT - Thread_create Exit (task=0x4c2b8) @0x0008af4b:[T:0x4000] OG - Global_atexit enter (fxn=0x1a00c) @0x0008b08e:[T:0x4000] OG - Global_atexit enter (fxn=0x1d17c) @0x0008b1fc:[T:0x4000] ti.sdo.ce.alg - ALG_init Enter @0x0008b2c9:[T:0x4000] OG - Global_atexit enter (fxn=0x1969c) @0x0008b3a7:[T:0x4000] ti.sdo.ce.alg - ALG_init Exit @0x0008b469:[T:0x4000] OG - Global_atexit enter (fxn=0x1913c) @0x0008b593:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008b67d:[T:0x4000] OM - Memory_alloc return (0x4e3f0) @0x0008b746:[T:0x4000] OG - Global_atexit enter (fxn=0x20610) @0x0008d57e:[T:0x4000] OG - Global_atexit enter (fxn=0x16808) @0x0008d68d:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008d778:[T:0x4000] OM - Memory_alloc return (0x4e450) @0x0008d844:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008d925:[T:0x4000] OM - Memory_alloc return (0x4e470) @0x0008d9ea:[T:0x4000] OM - Memory_alloc Enter(0x18) @0x0008dab6:[T:0x4000] OM - Memory_alloc return (0x4e490) @0x0008dc0f:[T:0x4000] CS - Server_init() @0x0008dcec:[T:0x4000] CS - Server_init Global_useLinkArbiter = 0 @0x0008ddb3:[T:0x4000] OG - Global_atexit enter (fxn=0x13144) @0x0008df60:[T:0x4000] OG - Global_atexit enter (fxn=0xf6bc) @0x0008e49f:[T:0x4002] OP - daemon thread created. @0x0008e5a5:[T:0x4002] OP - getCmd_d Enter (proc=0xbe7ffaec) @0x0008e675:[T:0x4002] ti.sdo.ce.osal.Sem - Entered Sem_pend sem[0x4c268] timeout[0x] Display Device: Standard NTSC selected @0x0011615d:[T:0x4000] OM - Memory_contigAlloc Enter(size=1036800, align=-1, cached=FALSE, heap=FALSE) @0x0011630e:[T:0x4000] OM - Memory_contigAlloc CMEM_alloc(1036800) = 0x40587000. @0x001163df:[T:0x4000] OM - Memory_contigAlloc CMEM_getPhys(0x40587000) = 0x844ec000. @0x00116479:[T:0x4000] OM - Memory__addContigBuf Enter(virtAddr=0x40587000, size=1036800, physAddr=0x844ec000) @0x0011650d:[T:0x4000] OM - Memory__addContigBuf creating new contigBuf object @0x0011658e:[T:0x4000] OM - Memory_alloc Enter(0x10) @0x00116645:[T:0x4000] OM - Memory_alloc return (0x4e5c0) @0x001166e2:[T:0x4000] OM - Memory__addContigBuf returning: cb-phys=0x844ec000, cb-size=1036800, cb-virt=0x40587000 @0x00116779:[T:0x4000] OM - Memory_contigAlloc return
RE: About the cache issues of dm6446
1) If you're using projects from elsewhere then the default won't really matter, you'll need to look at how it was configured by the person that created the tcf file. 2) Use the BCACHE module from BIOS. From: kashin Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 12:52 AM To: Griffis, Brad; [EMAIL PROTECTED] Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi, thanks for all of your answering. Brad, i still has some questions: 1. in document spru862a page 26 section 2.2, it says the L2 cache is enabled automatically when using DSP/BIOS, but in my default BIOS .tcf file, it seems all the L2 are used as SRAM. what is the correct default setting of L2 when using DSP/BIOS ? 2. in document spru862a, it discusses about some CSL APIs to use to do cache operation for c64x+, but you mentioned that there is no CSL for c64x+ in last letter. if its the case, how can i do the cache operations to assure cache coherency or setting MARs without CSL in DSP/BIOS ? thanks in advance best, kashin lin 2008/6/11, Griffis, Brad [EMAIL PROTECTED]: You're both looking at documents that do not apply to the DM6446. Please go to the DM6446 product folder for documents applicable to this device: http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html#technicald ocuments Kashin, the guide you are looking at applies to 64x cache, not 64x+ cache. The correct guide, as seen in the product folder above, is: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3tabId=4 09familyId=1302abstractName=spru862a Andre, there is not a CSL for DM6446 and so those CSL commands should not be used (they are written for 64x, not 64x+). DSP/BIOS has a set of APIs, BCACHE, that can be used for modifying the cache settings at run-time. These APIs are described in the BIOS documentation. You can find the BIOS documentation inside the individual BIOS releases. For example: bios_5_32_02/packages/ti/bios/doc To answer the original questions: 1) A new feature of the 64x+ cache is that L1 memory is also configurable as either SRAM or cache. The hardware defaults to 32KB L1P and 32KB L1D. However, your BIOS tcf file can override this. 2) The L2 defaults to all SRAM. However, this also can be overridden in the BIOS tcf file. When data buffers are stored in L1D or L2 you do not need to worry at all about cache coherence as that will be handled by the hardware. However, if your data is stored in external memory, then you must be more careful with coherence if the data is being accessed by more than one source (e.g. ARM, DSP, EDMA, etc.). Turning on the L2 cache is not enough for external memory to actually get cached. There are a set of registers called MAR (memory attribute register) where you must set the bit corresponding to a range of DDR in order for that range to be cacheable. Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Gaschler Sent: Wednesday, June 11, 2008 4:20 AM To: kashin Lin Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi, for enabling caches in run time have a look into http://focus.ti.com/lit/ug/spru401j/spru401j.pdf especially the CACHE section. If you want access CMEM/DSPLINK data for example (that should be in DDR 0x87 - 0x88 ) you simply #include csl_cache.h to your DSP code and write CACHE_enableCaching ( CACHE_EMIFA_CE07 ) ; // Cache CMEM/DSPLINK area that is at the end of DDR memory L2SRAM is cached by default, DDR is not (so you probably want to enable that in run time). -- Andre Subject: About the cache issues of dm6446 From: kashin Lin [EMAIL PROTECTED] Date: Wed, 11 Jun 2008 15:51:23 +0800 To: davinci-linux-open-source@linux.davincidsp.com To: davinci-linux-open-source@linux.davincidsp.com Hi, i have read the DSP two-level internal memory reference guide (spru610) DSP cache user guide (spru656) but still have some questions about the dm6446 DSP side's cache: 1. by reading these two guides, it seems that level-1 memory ( L1D, L1P) are always used as cache and level-2 can be configured as SRAM or cache. but i found that on the dm6446 memory map described in sprs283 and .tcf file when using DSP/BIOS, there is a memory region named L1D RAM ranged from 0x11f04000 ~ 0x11f0 and another named L1D RAM/cache ranged from 0x11f1 ~ 0x11f17fff. does it mean L1D can also be configured as RAM or cache? how? any restriction? 2. when using DSP/BIOS on dm6446, does it defaultly set all L2 memory as SRAM (64K) and L1D and L1P as caches? should i enable the caches in run-time? and what are the default cacheability setting of L2SRAM and DDR(external memory)? thanks in advance. best,
RE: cmem issure of DVEVM_1_30
Udev is there, it just looks different in the 2.6.23 kernel. CMEM
v2.00.01 was written for the 2.6.10 kernel. Sometime between 2.6.10 and
2.6.23 the 'class_simple' interface was replaced by 'class'. Later
CMEMs support both interfaces, dependant on:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18)
#undef USE_CLASS_SIMPLE
#else /* LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18) */
#define USE_CLASS_SIMPLE
#endif /* LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18) */
...
...
#ifdef USE_CLASS_SIMPLE
cmem_class = class_simple_create(THIS_MODULE, cmem);
#else
cmem_class = class_create(THIS_MODULE, cmem);
#endif
if (IS_ERR(cmem_class)) {
__E(Error creating cmem device class.\n);
err = -EIO;
goto fail_after_reg;
}
#ifdef USE_CLASS_SIMPLE
class_simple_device_add(cmem_class, MKDEV(cmem_major, 0), NULL,
cmem);
#else
class_device_create(cmem_class, NULL, MKDEV(cmem_major, 0), NULL,
cmem);
#endif
So you have a few options:
- stick with what you're doing
- manually modify your cmemk.c file to convert usage of
class_simple to class (quite easy), and use USE_UDEV=1
- upgrade to CMEM 2.10 or later
Regards,
- Rob
-Original Message-
From: steven.zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 10:21 PM
To: Tivy, Robert
Cc: davinci
Subject: RE: cmem issure of DVEVM_1_30
Yes,USE_UDEV is disable.
If I enable it, compile error arises.
class_simple_create not define.
My kernel version is 2.6.23 which is cut from davinci tree.
As I know, udev is included in almost every 2.6 kernel based
Linux distribution.But why davinci kernel tree does not support it?
However, I can create /dev/cmem manually with the help of Andre.
Thanks.
Steven
On Wed, 2008-06-11 at 12:15 -0500, Tivy, Robert wrote:
Steven,
Did you use the provided Makefile (which includes ../../Rules.make)?
There is a macro USE_UDEV that needs to be set to 1 in order to get
insmod-time /dev/cmem creation. This setting of USE_UDEV
is usually
done in the provided 'make' file Rules.make and is
'consumed' in the
rule to build cmemk.c.
Regards,
- Rob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of steven.zhang
Sent: Tuesday, June 10, 2008 11:08 PM
To: davinci
Subject: cmem issure of DVEVM_1_30
Hi, all.
Days before, I updated my evm to 1.30.
cmem module is also upgraded to cmem_2_00_01 from cmem_1_02.
And succeed in building cmemk.ko.However, after running
loadmodules.sh, everything seems right, but I can not
find any cmem
entry in /dev/! What can be the problem?
The following message is grabbed while insmod cmemk.ko.
[EMAIL PROTECTED]:/opt/dvevm# ./loadmodules.sh
ioremap_nocache(0x8780, 8388608)=0xc900
ioremap_nocache(0x8780, 8388608)=0xc900 6allocated heap
buffer 0xc900 of size 0xf7000 allocated heap buffer
0xc900
of size 0xf7000 6cmem initialized 4 pools between
0x8780 and
0x8800 cmem initialized 4 pools between 0x8780 and
0x8800
dsplinkk: no version for struct_module found: kernel tainted.
dsplinkk: no version for struct_module found: kernel tainted.
1DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008 Time:
13:32:41
DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008
Time: 13:32:41
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sour
ce
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: About the cache issues of dm6446
Hi everybody thanks for your anwers. Since there is no L1D cache on the 6727, there is no need to victimize a single cache line - what I meant is to force the cache to refresh a specific cache line and force it to refetch data from external memory. Are you sure that the 6727 has no L1D? and if so, what is the L2 latency for data fectching? Thanks again Albert On Thu, Jun 12, 2008 at 3:43 PM, Griffis, Brad [EMAIL PROTECTED] wrote: 6727 has ONLY L1P (i.e. there is no L1D and no L2). Its L1P is not configurable as SRAM. I'm not sure I understand your question about the single cache line. The cache always operates on cache lines, so yes, a single cache line can be a victim. How much does what take? -- *From:* Albert Burbea [mailto:[EMAIL PROTECTED] *Sent:* Wednesday, June 11, 2008 4:22 PM *To:* Griffis, Brad *Cc:* Andre Gaschler; kashin Lin; davinci-linux-open-source@linux.davincidsp.com *Subject:* Re: About the cache issues of dm6446 Hi another question - is it possible to victimize a single cache line? How much does it take? Also, Brad, are your remarks valid on the 6727 floating point TI DSP? 10x On 6/11/08, *Griffis, Brad* [EMAIL PROTECTED] wrote: You're both looking at documents that do not apply to the DM6446. Please go to the DM6446 product folder for documents applicable to this device: http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html#technicald ocuments Kashin, the guide you are looking at applies to 64x cache, not 64x+ cache. The correct guide, as seen in the product folder above, is: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3tabId=4 09familyId=1302abstractName=spru862a Andre, there is not a CSL for DM6446 and so those CSL commands should not be used (they are written for 64x, not 64x+). DSP/BIOS has a set of APIs, BCACHE, that can be used for modifying the cache settings at run-time. These APIs are described in the BIOS documentation. You can find the BIOS documentation inside the individual BIOS releases. For example: bios_5_32_02/packages/ti/bios/doc To answer the original questions: 1) A new feature of the 64x+ cache is that L1 memory is also configurable as either SRAM or cache. The hardware defaults to 32KB L1P and 32KB L1D. However, your BIOS tcf file can override this. 2) The L2 defaults to all SRAM. However, this also can be overridden in the BIOS tcf file. When data buffers are stored in L1D or L2 you do not need to worry at all about cache coherence as that will be handled by the hardware. However, if your data is stored in external memory, then you must be more careful with coherence if the data is being accessed by more than one source (e.g. ARM, DSP, EDMA, etc.). Turning on the L2 cache is not enough for external memory to actually get cached. There are a set of registers called MAR (memory attribute register) where you must set the bit corresponding to a range of DDR in order for that range to be cacheable. Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Gaschler Sent: Wednesday, June 11, 2008 4:20 AM To: kashin Lin Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi, for enabling caches in run time have a look into http://focus.ti.com/lit/ug/spru401j/spru401j.pdf especially the CACHE section. If you want access CMEM/DSPLINK data for example (that should be in DDR 0x87 - 0x88 ) you simply #include csl_cache.h to your DSP code and write CACHE_enableCaching ( CACHE_EMIFA_CE07 ) ; // Cache CMEM/DSPLINK area that is at the end of DDR memory L2SRAM is cached by default, DDR is not (so you probably want to enable that in run time). -- Andre Subject: About the cache issues of dm6446 From: kashin Lin [EMAIL PROTECTED] Date: Wed, 11 Jun 2008 15:51:23 +0800 To: davinci-linux-open-source@linux.davincidsp.com To: davinci-linux-open-source@linux.davincidsp.com Hi, i have read the DSP two-level internal memory reference guide (spru610) DSP cache user guide (spru656) but still have some questions about the dm6446 DSP side's cache: 1. by reading these two guides, it seems that level-1 memory ( L1D, L1P) are always used as cache and level-2 can be configured as SRAM or cache. but i found that on the dm6446 memory map described in sprs283 and .tcf file when using DSP/BIOS, there is a memory region named L1D RAM ranged from 0x11f04000 ~ 0x11f0 and another named L1D RAM/cache ranged from 0x11f1 ~ 0x11f17fff. does it mean L1D can also be configured as RAM or cache? how? any restriction? 2. when using DSP/BIOS on dm6446, does it defaultly set all L2 memory as SRAM (64K) and L1D and L1P as caches?
RE: About the cache issues of dm6446
Albert, This is off topic. Please post your question here in the floating point section: https://community.ti.com/forums/ Brad From: Albert Burbea [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 12:28 PM To: Griffis, Brad Cc: Andre Gaschler; kashin Lin; davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi everybody thanks for your anwers. Since there is no L1D cache on the 6727, there is no need to victimize a single cache line - what I meant is to force the cache to refresh a specific cache line and force it to refetch data from external memory. Are you sure that the 6727 has no L1D? and if so, what is the L2 latency for data fectching? Thanks again Albert On Thu, Jun 12, 2008 at 3:43 PM, Griffis, Brad [EMAIL PROTECTED] wrote: 6727 has ONLY L1P (i.e. there is no L1D and no L2). Its L1P is not configurable as SRAM. I'm not sure I understand your question about the single cache line. The cache always operates on cache lines, so yes, a single cache line can be a victim. How much does what take? From: Albert Burbea [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 4:22 PM To: Griffis, Brad Cc: Andre Gaschler; kashin Lin; davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi another question - is it possible to victimize a single cache line? How much does it take? Also, Brad, are your remarks valid on the 6727 floating point TI DSP? 10x On 6/11/08, Griffis, Brad [EMAIL PROTECTED] wrote: You're both looking at documents that do not apply to the DM6446. Please go to the DM6446 product folder for documents applicable to this device: http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html#technicald ocuments Kashin, the guide you are looking at applies to 64x cache, not 64x+ cache. The correct guide, as seen in the product folder above, is: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3tabId=4 09familyId=1302abstractName=spru862a Andre, there is not a CSL for DM6446 and so those CSL commands should not be used (they are written for 64x, not 64x+). DSP/BIOS has a set of APIs, BCACHE, that can be used for modifying the cache settings at run-time. These APIs are described in the BIOS documentation. You can find the BIOS documentation inside the individual BIOS releases. For example: bios_5_32_02/packages/ti/bios/doc To answer the original questions: 1) A new feature of the 64x+ cache is that L1 memory is also configurable as either SRAM or cache. The hardware defaults to 32KB L1P and 32KB L1D. However, your BIOS tcf file can override this. 2) The L2 defaults to all SRAM. However, this also can be overridden in the BIOS tcf file. When data buffers are stored in L1D or L2 you do not need to worry at all about cache coherence as that will be handled by the hardware. However, if your data is stored in external memory, then you must be more careful with coherence if the data is being accessed by more than one source (e.g. ARM, DSP, EDMA, etc.). Turning on the L2 cache is not enough for external memory to actually get cached. There are a set of registers called MAR (memory attribute register) where you must set the bit corresponding to a range of DDR in order for that range to be cacheable. Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Gaschler Sent: Wednesday, June 11, 2008 4:20 AM To: kashin Lin Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: About the cache issues of dm6446 Hi, for enabling caches in run time have a look into http://focus.ti.com/lit/ug/spru401j/spru401j.pdf especially the CACHE section. If you want access CMEM/DSPLINK data for example (that should be in DDR 0x87 - 0x88 ) you simply #include csl_cache.h to your DSP code and write CACHE_enableCaching ( CACHE_EMIFA_CE07 ) ; // Cache CMEM/DSPLINK area that is at the end of DDR memory L2SRAM is cached by default, DDR is not (so you probably want to enable that in run time). -- Andre Subject: About the cache issues of dm6446 From: kashin Lin [EMAIL PROTECTED] Date: Wed, 11 Jun 2008 15:51:23 +0800 To: davinci-linux-open-source@linux.davincidsp.com To: davinci-linux-open-source@linux.davincidsp.com Hi, i have read the DSP two-level internal memory reference guide (spru610) DSP cache user guide (spru656) but still have some questions about the dm6446 DSP side's cache: 1. by reading these two guides, it seems that level-1 memory ( L1D, L1P) are always used as cache and level-2 can be configured as SRAM or cache. but i found that on the dm6446 memory map described in sprs283 and .tcf file when using DSP/BIOS, there is a memory region named L1D RAM ranged from
