在移植linux2.6.18.1到龙芯3210的时候,也就是在移植笔记3里,对Cache和TLB进行了一段修改,移植的时候以对照的方式进行修改,现在来看看,为什么代码这样写。
在移植笔记3里面已经知道,对Cache和TLB的操作是在trap_init里完成的,查了一下trap的英文意思,有一个解释是"存水弯"。
然后进入per_cpu_trap_init,看到两个函数的调用:
cpu_cache_init();
tlb_init();
对了,正是这两个函数。
先来看cpu_cache_init:
在./arch/mips/kernel/cpu-probe.c里我们加入了一段代码:
(在cpu_probe_legacy函数里)
switch (c->processor_id & 0xff00) {
case ... ...
... ...
case PRID_IMP_SOC32101:
c->cputype = CPU_SOC32101;
c->isa_level = MIPS_CPU_ISA_II;
c->options = R4K_OPTS |
/* MIPS_CPU_FPU | */ MIPS_CPU_LLSC;
c->tlbsize = 48;
break;
}
看到c->options的值是R4K_OPTS
而:
#define R4K_OPTS (MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_4K_CACHE /
| MIPS_CPU_COUNTER)
明显地,c->options记录的就是选定一些关于该CPU的一些特性。而这些特性就成了判断的标志位,从而选择不同的初始化,其中MIPS_CPU_4K_CACHE特性就是关于Cache的。
回到cpu_cache_init函数,在./arch/mips/mm/cache.c里。
该函数就是根据不同的CPU特性来决定用哪个函数初始化我们的cache。
在./include/asm-mips/cpu-features.h定义了这个判定宏:
#define cpu_has_4k_cache (cpu_data[0].options & MIPS_CPU_4K_CACHE)
显然,对cache的初始化是由r4k_cache_init来执行的。
进入r4k_cache_init,看到:
probe_pcache();
从函数名来看,这个函数的作用是探测cache,换句话说,就是获取cache的有关信息。进入该函数,我们发现,根据不同的CPU类型进行了不同的计算,来确定cache的属性。
926 case CPU_SOC32101:
927 icache_size = 1 << (12 + ((config & CONF_IC) >> 9));
928 c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
929 if (prid & 0x3) {
930 c->icache.ways = 4;
931 } else {
932 c->icache.ways = 2;
933 }
934 c->icache.waybit= 0;
935
936 dcache_size = 1 << (12 + ((config & CONF_DC) >> 6));
937 c->dcache.linesz = 16 << ((config & CONF_DB) >> 4);
938 if (prid & 0x3) {
939 c->dcache.ways = 4;
940 } else {
941 c->dcache.ways = 2;
942 }
943 c->dcache.waybit = 0;
944 break;
确定指令cache和数据cache的大小属性,保存在cache_desc中。
24 struct cache_desc {
25 unsigned short linesz; /* Size of line in bytes */
26 unsigned short ways; /* Number of ways */
27 unsigned short sets; /* Number of lines per set */
28 unsigned int waysize; /* Bytes per way */
29 unsigned int waybit; /* Bits to select in a cache set */
30 unsigned int flags; /* Flags describing cache properties */
31 };
计算方法,龙芯3210,跟其它MIPS的CPU不同,查看芯片手册:
查看Config寄存器的描述:
现在应该知道为什么这么算了。
至于对cache_desc其它成员的赋值操作,根据cache的分组结构的公式来决定
由于龙芯的cache是采用了路组级联的方式,所以结构概念上,有路数目(ways),路大小(waysize)、组数目(sets)、行大小(linesz)等。換算公式为:
waysize = cachesize / ways
sets = waysize / linesz
waybit = log2(waysize)
1006 c->icache.waysize = icache_size / c->icache.ways;
1007 c->dcache.waysize = dcache_size / c->dcache.ways;
1008
1009 c->icache.sets = c->icache.linesz ?
1010 icache_size / (c->icache.linesz * c->icache.ways) : 0;
1011 c->dcache.sets = c->dcache.linesz ?
1012 dcache_size / (c->dcache.linesz * c->dcache.ways) : 0;
也就是说,一级的cache分为ways个路,每路cache对应索引的行为一组set。其中waybit是每路数据的位大小。
不过这里的waybit被直接赋值为0了,还不了解这个waybit的意义所在。
至于最后一个成员变量flags,根据注释是指示cache的一些其它属性。
接下来是setup_scache这个函数
进入这个函数,显然,该函数的功能是获取二级cache的属性信息,龙芯3210没有二级cache,所以这个函数就不去理会了。其实二级cache获取属性信息的过程跟一级cache差不多。
再接下来的操作是:
r4k_blast_dcache_page_setup();
r4k_blast_dcache_page_indexed_setup();
r4k_blast_dcache_setup();
r4k_blast_icache_page_setup();
r4k_blast_icache_page_indexed_setup();
r4k_blast_icache_setup();
这几个函数实际上为一操作指针函数赋值。对应于./include/asm-mips/r4kcache.h中的宏函数:
343 #define __BUILD_BLAST_CACHE(pfx, desc, indexop, hitop, lsize) /
344 static inline void blast_##pfx##cache##lsize(void) /
345 { /
346 unsigned long start = INDEX_BASE; /
347 unsigned long end = start + current_cpu_data.desc.waysize; /
348 unsigned long ws_inc = 1UL << current_cpu_data.desc.waybit; /
349 unsigned long ws_end = current_cpu_data.desc.ways << /
350 current_cpu_data.desc.waybit; /
351 unsigned long ws, addr; /
352 /
353 __##pfx##flush_prologue /
354 /
355 for (ws = 0; ws < ws_end; ws += ws_inc) /
356 for (addr = start; addr < end; addr += lsize * 32) /
357 cache##lsize##_unroll32(addr|ws,indexop); /
358 /
359 __##pfx##flush_epilogue /
360 }
这个函数的語法在博客中另一篇文章《inux内核中的一个宏函数例子》中已有解释。
从这个宏函数中好像看到了“waybit”这个值,之前没弄清楚其作用,在这里可以看到了。猜想ws为way select,那么waybit就是路选的意思了。参考了网络资料《mips.cache.arch》,才搞明白,原来使用index类型操作时,地址包括了路选。其中在路选地址中,有MSB和LSB两种方式,这下明白了waybit的意义了,那么计算方式应该也有两种:
MSB:waybit = log2(waysize)
LSB:waybit = 0
而龙芯用的方式就是LSB,这也是为什么直接给waybit赋值为0的原因。
除了以上的以index方式外,还有hit方式:
362 static inline void blast_##pfx##cache##lsize##_page(unsigned long page) /
363 { /
364 unsigned long start = page; /
365 unsigned long end = page + PAGE_SIZE; /
366 /
367 __##pfx##flush_prologue /
368 /
369 do { /
370 cache##lsize##_unroll32(start,hitop); /
371 start += lsize * 32; /
372 } while (start < end); /
373 /
374 __##pfx##flush_epilogue /
375 }
明显地,hit方式比index方式简洁,这是因为hit方式只管一个物理标志匹配的过程,而不用去理会每组内的具体情况。
看到这里,从代码上,可以理解了Cache的初始化情况,但是对Cache的具体工作原理,还是比较模糊,这个问题另外开一篇文章来谈下体会,主要还是参考《See Mips Run》。
接下来看TLB
tlb_init函数中对TLB进行了初始化
-----《未完待续》