vxWorks compress rom的解压缩速度问题，MIPS 24KEC CACHE 4路组相连

李四

vxWorks compress rom的解压缩速度问题，MIPS 24KEC CACHE 4路组相连 [复制链接]

 手上在做一个用MIPS32   24KEC的项目，CACHE这块似乎我一直没调对，后边都起的差不多了但是这里仍然有问题

体现如下：无论在config0最后3bit写0，2，3，7   就是写透关闭写回还有一个是UNCACHE 加速~不是很明白~总之几个CACHE选项都试过了，最终的一个vxworks启动时间都差不多

vxworks启动是先把flash数据段复制到ram，再从flash进行解压缩到ram的操作，都是使用kseg0.
我修改了下romstart为整个复制flash,再从ram解压缩到ram。但是一共200K不到的image解压缩解了足足30多秒，无论我config0写的什么，时间都差不多。

想来想去也只有cache初始化有问题了。
初始化我主要是借鉴过see   mips   run里的初始化流程，感觉I   CACHE不会有问题，因为有cache   fill
但是d   cache初始化就有问题了，书上的两路组相连CACHE初始化我还可以理解，但是4路怎么办呢？
似乎还有一个WAY   SELECT   ARRAY的存在用于选择4路CACHE   。

另外手上有LINUX的代码，我完全着做结果也是一样。LINUX   DCACHE   初始化代码如下：

      li         a2,       CFG_CACHE_LINE_SIZE     /*16K*/
      /*   kseg0   mem   address       这里就跟注释不一样，这里给的是物理地址啊，书上用的都是虚拟地址*/      
      li         a1,       0
      /*   total   number   of   lines   */
      li         a3,     CFG_CACHE_LINE_NO   *   CFG_CACHE_NO_WAYS     /*4路     128行*/

1:   
      /*   store   tag   (invalid,   not   locked)   */
      cache   0x8,     0(a1)                                     /*第二个不懂的地方为什么用0x8   index_Store_tag_I     I   CACHE前面有初始化代码啊*/
      cache   0x9,     0(a1)                                     /*这里是第一轮D   cache   clear   tag   顺便说一下tag那几个cp0寄存器最前面已经清0了*/

      add       a3,     -1
      bne       a3,     zero,   1b
      add       a1,     a2
      
mfc0 a0,   CP0_ECC
li a1,   ECC_WST
or a0,   a1
mtc0 a0,   CP0_ECC

li a0,   K0BASE
move a2,   t3 #   dcacheSize
move a3,   t5 #   dcacheLineSize
move a1,   a2

CACHEOP(a0,a1,a2,a3,Index_Store_Tag_D)
    /*
            宏定义LOOP   相当于
                    for(addr-kseg0;addr                     Index_Store_Tag_D(addr)
*/
/*   Clear   WST   bit   */
mfc0 a0,   CP0_ECC
li a1,   ~ECC_WST
and a0,   a1
mtc0 a0,   CP0_ECC
到这里为止DCACHE初始化就完成了。
这一段就是我不明白的第三个部分，书上说2路组相连由于怕对同一路初始化了两次所以需要用一个junk循环来miss   D   cache
                    for(addr-kseg0;addr                     junk=*addr

我的理解是如果需要初始化4路，那是不是需要有3次junk   读来初始化？？但是实际上LINUX代码里并没有给出类似的东西。而是在设置了CP0_ERRCTL寄存器后做了一些操作。
我严重怀疑LINUX   CACHE也没整对，因为LINUX的东西一开开3分钟，谁受得了。


顺便说一下肯定是CACHE初始化有问题的原因是之前有4KC的项目，处理器频率只有现在这个的一半，但是就10几秒什么都完事了。现在这个肯定是有问题。

我想请教一下到底MIPS   架构CPU   4路组相连的CACHE应该如何初始化？



更新一下~~
里面D   CACHE初始化中line*way总共clear   tags这么多次，我的理解已经将所有4路的cache   进行了clear   tag了，因为已经有4组相同index但是tag不同的东西写入了cache   
但是前面那个   index_Store_tag_I       还是不知道是干什么的

另外在ECC_WST   这位SET以后做的操作也不知道是什么意义


最后补充一个问题~~~FLASH能被CACHE吗？？如果把CACHE设置为写透或写回，一读0x90000000就BUS   ERROR了~~是不是因为我EBU的WRITE   PROTECT没打开？

hj520

是否能cachable,一，合并读操作没有影响，访问顺序交换是否有影响，比如一块区域，以BYTE，WORD,DWORD访问没关系，而且相邻的读操作可以合并，读操作前后交换对设备也没影响；二，是否会被其他设备修改，比如PCI外设，CPU可以修改的同时，外设也会修改，如果cache打开，那么双方的操作就不同步了。

如果是只读的flash，那是cachable的，反正就只有读操作，而Flash得读操作跟memory一样，合并操作和顺序交换没影响。但是如果是可读写的flash，那就要另外考虑了。因为flash是靠一系列指令完成的。如果设置成Cacheable,会导致写操作指令被合并，或者时间上的先后顺序得不到保证。以Intel 16位falsh比如要写0x55aa到0xfe000000的地方，指令应该是
0xfe000000=0x5000
0xfe000000=0x4000
0xfe000000=0x55aa
0xfe000000=0x5000
如果这个顺序被cache交换或者合并了，那必然操作失败。

yyb0034

使用的是普通的NOR FLASH，只有在使用特定写命令才能对其修改，应该算是只读的了吧

另外现在的状况是CACHE初始化完毕之后读FLASH的CACHE地址，就是0x90000000就挂了，我把整个系统带起来再访问，返回的错误是DATA BUS ERROR

如果禁用了CACHE就可以正常访问。我想这还是出在DATA CACHE的初始化问题上。

huleisheng

不好意思，我对MIPS不是很熟悉，以前是用过MIPS4K，但是看问题应该是出在设置上面。
另外就是你说的特定写命令应该是需要通过写flash所在的内存空间才能实现的，所以还是受cache影响的。

能不能看到cause register的值，如果可以，看看excCode,看看是什么类型的异常。

s110400710

另外能不能看EPC的值，里面是出错指令的地址，然后对应反汇编后后的代码，从而确定是程序哪里出了错。

thelastzen

是这样，VXWORKS本身romStart那些复制DATA段，解压缩。这些所有的命令都在flash里取的命令。
FLASH的地址有两段，UNCACHE从0xb0000000开始，cache的从0x90000000开始
现在如果把flash首地址用宏定义为0x90000000，到执行的时候就会从0x90000000地址取指令，当然是在bfc00000入口后做了一些初始化后跳过去的
现在如果这么做，打开CACHE后，完全执行不下去，到跳转到0x90000000段地址后就会死

如果不开CACHE或者开CACHE但是把FLASH首地址定义为0xb0000000，那么其他什么都不用改整个系统可以跑起来，但是特别慢，可以确定是在执行inflate这个函数的时候花费极大的时间。我甚至想试试把inflate函数整个LOCK到I cache里，但是执行到这个cache 0x1c就挂了

还有就是用点灯判断，在开了CACHE后执行一条从0x90000000地址读东西的指令后就会死掉。如果开CACHE并用0xb0000000的flash地址后正确执行到vxworks shell起来后输入个d 0x90000000 的shell命令，结果这样：
-> d 0x90000000
90000000:  
Data bus error
Exception Program Counter: 0x8008778c
Status Register: 0x0000ff01
Cause Register: 0x0000001c
Error address: 0xffffffff, Error ID: 0x0000

8009d034 d              +224: d (ffffffff, ffffffff, 0, 81f735b0)
8009d034 d              +224: printf (1, 0, 0, 0)
80023340 vxTaskEntry    +c  : shell (1, 0, 0, 0)
8009becc shell          +16c: 8009b9d0 (eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee)
8009bbb8 shellIsRemoteConnectedGet+614: execute (800d7511, 81f711f4, 7f, 8)
8009bcec execute        +dc : yyparse (8009bab8, 0, 0, 0)
800a8198 yyparse        +81c: 800a60f4 (0, 0, 0, 0)
800a62a8 yystart        +970: d (eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee)
8009d034 d              +224: printf (800d8aa6, 90000000, 3, 0)
shell restarted.

81f735b0地址的内容似乎是个sw还是什么。但是我觉得不是flash禁止写造成的
因为如果同样输入d 0xb0000000就没问题。显然0xb0000000对应的也是同一块flash的同一个地址。
至于flash操作那些跟cache错误没什么关系，要对flash操作的时候用的都是0xb0000000的地址，肯定不会出cache问题

以前有个用mips 4kc的项目，BSP也类似，那个才4K的I 4K的D CACHE ，2路组相连，速度150M，解几M的IMAGE到启动不过10秒。区别就是flash宏定义是0x90000000，就是上电以后relocale到cache空间里。而新的这个频率是原来的2倍多，CACHE大小是4倍，4路组相连，结果解一个200K不到的IMAGE要30多秒。如果也能执行在CACHE空间内，我想肯定比4KC的机器解的快。

我记得以前在什么地方读过一篇文章说不是所有FLASH都满足可CACHE条件的。因为现在手上的FLASH只是一块8*512 =4M BIT的FLASH，原来那个是4M BYTE 16BIT宽的。现在我真挺想把问题赖到硬件不一样上呢~()~ 但是没有试完以前不能这么下结论，所以还是要继续调。
有没有什么特殊的条件判断FLASH是否可以被CACHE啊

lanhaitun520

是DBE， CPU的写操作造成的，跟flash没关系。应该是cache配置不对。

ardentyears

果然是CACHE不对啊= =
请问这样可以判断出是DCACHE错还是ICACHE错吗？？

还有这种4路组相连的CACHE一般如何进行初始化呢
目前的初始化流程：

   /* cache line size */
   li    a2,   CFG_CACHE_LINE_SIZE
   /* kseg0 mem address */
   li    a1,   0
   /* total number of lines */
   li    a3,  CFG_CACHE_LINE_NO * CFG_CACHE_NO_WAYS

1:
   /* store tag (invalid, not locked) */
   cache 0x8,  0(a1)
   cache 0x9,  0(a1)

   add   a3,  -1
   bne   a3,  zero, 1b
   add   a1,  a2
首先这段把整个16K大小的DCACHE都index_Store_tag_D了，但是之前在同一个循环里先做了一步index_Store_tag_I，不知道为什么

之后把ERRCTRL的CP0寄存器的WST设置为1，把WAY SELECT ARRAY整个清0，大概应该是这样。之后就没有别的了~还需要啥吗？  
      

zhouxinsee

另外~~如果配置有错误跟FLASH没关系为什么同样的CACHE空间 0x80000000就可以正常工作呢？？至少存读没问题

今天我再去确认一下0x80000000里面打开CACHE会不会有明显的速度提升。

davidli88

确认了一下，如果在0x80000000内CACHE工作还是比较正常的
如果解压缩已经link到0x80000000段内，然后在CACHE开和关进行解压缩区别不小，一个不足一秒就解完了，一个要用4秒

xiongjunfeng

是DCACHE的问题。我看你代码里没有初始化TagLo,TagHi,是不是前面已经有初始化了？
我认为2-way和4-way初始化应该没区别，只要能覆盖到就可以了。
不明白为什么有cache   0x8,     0(a1)。

xwell

继续更新，现在用了非常土的办法暂时解决这个问题，在编image时直接把flash地址连接到0x80000000去然后初始化完了就完全拷贝过去再执行~~~但是还是想仔细扣一扣这个初始化的问题

anzx23

另外，你的TLB是怎么初始化的？

luodongdong

我没初始化TLB~~因为只用了KESG0 KESG1，这两段不都是FIX MAPPING么
另外昨天得到一种回答是因为FLASH速度跟不上CPU导致的~~~CPU速度是400M~~~
有没有可能是这样的情况？

lgspace

“FLASH速度跟不上CPU导致的”，这个说法让人想不通啊？就是因为CPU速度比外面快多了采用cache技术，如果外设速度能跟上CPU，那还要cache干嘛？而其你24K的CPU应该是动态调度的吧，乱序执行对外设的依赖就更低了。
另外，TagLo,TagHi的问题，你没说。

水品有限，没其他信息能提供了。

老乐

TAGLO TAGHI？？如果是说用来FILL的那几个CP0，那在初始化前全部都清0了。如果是TLB的那些，没有动过，因为只用了FIX MAPPING的 KESG0 KESG1

“FLASH速度跟不上CPU导致的”，这个说法让人想不通啊？~~~我也很想不通~~~很牵强的解释。

strongli

问题搞定了没有？建议你手工对TagLo,TagHi清零

ykfall

我晕。。。。初始化的时候当然要先清0


我现在是把本来在flash里的指令连接的时候直接连接到0x80000000去，然后上电在cache初始化好后把0xb0000000复制到0x80000000去，然后再跳到ram里执行。


也有人说是因为flash不支持burst模式所以不能被cache。感觉比那个FLASH速度跟不上CPU速度的解释说服力强一些。我还是再看看flash手册吧。

thtgan

你仿佛很不耐烦的样子。没人能帮你Debug,还得自己来,别人只能给你一些提示。实际上你上面会问2路和4路cache初始化有什么不一样是因为你没搞清楚什么叫set associative cache.

电源

汗~~~~~我有出现不耐烦的样子么？？？？？？orz没有这个意思~恩

我说我晕的意思是我不明白你说的taglo taghi清零是具体指啥~

如果说是保证store fill有正确的tag的话那应该是指最早在初始化前的这么几行代码吧？
        mtc0        zero, CP0_TAGLO
        mtc0        zero, CP0_TAGLO,1
        mtc0        zero, CP0_TAGLO,2
        mtc0        zero, CP0_TAGLO,3
        mtc0        zero, CP0_TAGLO,4

TagLo,TagHi这俩在初始化前都是手动清0的，另外这个是MIPS32的所以似乎不用那个taghi，另外在cpu手册上的CP0寄存器中也找不到taghi，先是把最一开始的一段内存先清0，然后清几个TAG寄存器。~似乎书上说是为了保证有效位没有置位，同时得到正确的奇偶校验。之后进行STORE TAG也还可以理解。FILL算是清奇偶校验等状态位。我的理解到这里还没错吧？？

我的理解是FILL的目的是保证CACHE有非错误的数据，这样。DATA的JUNK LOAD是因为组相连的原因。组相连应该就是set associative cache对吧？

另外我对组相连CACHE的理解：同一个TAG数值有两块或4块可以存储数据的地方，这样在计算出同一个TAG时不会马上无效后从写cache，而是把另外一路的存储空间写上第二次命中的内容。之后怎么淘汰一般都是那个LRU规则吧。这样是否对捏

假设片上有64K 4路组相联的DCACHE，那么DCACHE的总大小就是64K，一路为16K，那么顺序的从0~64K进行一次FILL或类似的操作就完整的把4路的CACHE都占用了对吧？其中0~16K让第一路CACHE写上了东西，那么16~32K就用了第二路，32~48K用了第三路，48~64K用了第四路。之后CACHE更新什么的取决于使用CACHE的地址计算出来的TAG和这个TAG的4块空间的状态。这样对不？我基本就是安这样的理解做的初始化。

如果我的理解有问题那就是初始化CACHE的问题。如果这块理解没错的话，那我想可以怀疑一下是否是别的地方出问题了~恩。