有关打开mmu附近的一些问题

duanius

最近在看head.S 基于 http://bbs.chinaunix.net/thread-2039668-1-1.html ，问题真不少。。。

00167:         mcr        p15, 0, r4, c2, c0, 0                @ load page table pointer
00168:         b        __turn_mmu_on
00169:
00170: /*
00171:  * Enable the MMU.  This completely changes the structure of the visible
00172:  * memory space.  You will not be able to trace execution through this.
00173:  * If you have an enquiry about this, *please* check the linux-arm-kernel
00174:  * mailing list archives BEFORE sending another post to the list.
00175:  *
00176:  *  r0  = cp#15 control register
00177:  *  r13 = *virtual* address to jump to upon completion
00178:  *
00179:  * other registers depend on the function called upon completion
00180:  */
00181:         .align        5
00182:         .type        __turn_mmu_on, %function
00183: __turn_mmu_on:
00184:         mov        r0, r0
00185:         mcr        p15, 0, r0, c1, c0, 0                @ write control reg
00186:         mrc        p15, 0, r3, c0, c0, 0                @ read id reg
00187:         mov        r3, r3
00188:         mov        r3, r3
00189:         mov        pc, r13
        
有关00181:         .align        5
作者解释“是我们要把打开mmu的操作放到一个单独的cache line上. 而在之前的"启动条件"一节我们说了,I Cache是可以打开也可以关闭的,这里这么做的原因是要保证在I Cache打开的时候,打开mmu的操作也能正常执行.”   
我的问题是， 即使不在一个cache line，又会有什么问题呢?


另外，对于 00186:         mrc        p15, 0, r3, c0, c0, 0                @ read id reg 这行也不理解，如果为了凑等待ttb set的周期，后面nop2个周期应该就够了，不理解在这里是为啥？

cuibixiong_cu

第二个问题我可以回答一下
00183: __turn_mmu_on:
00184:         mov        r0, r0
00185:         mcr        p15, 0, r0, c1, c0, 0                @ write control reg
00186:         mrc        p15, 0, r3, c0, c0, 0                @ read id reg
00187:         mov        r3, r3
00188:         mov        r3, r3
00189:         mov        pc, r13

其中185是enable MMU register，但是你有没有想过这个问题，在执行189的时候，MMU register是否真的已经enable了？这个主要涉及到一些bus transaction的问题，我可以明确的告诉你，不一定！一般来说，CPU的Write instruction只是将数据打到了BUS上，而Bus是否真的写到了Mem/Register上，则是Bus应该考虑的事情，假如在SMP系统上 两个CPU要同时写一个地址，请问谁先谁后？这个能说清楚吗？

所以在执行完185后，执行了两条mov r3 , r3指令，其实就是为了wait for mcr instruction completed，保证在执行189时候真的MMU有作用

不过你有没有考虑到执行了两条mov r3, r3就能保证mcr instruction就能完成了吗？其实也不一定，所以更好的办法就是用ISB，让instruction bus transaction全部完成，这样就一定没问题了

我建议你看看一份ARM MEMORY Barrier cookbook的文档，写的很详细！

duanius

回复 2# cuibixiong_cu


    hi 感谢你的回复
不过你没看懂我问的疑惑  我奇怪的地方不是两个187和188两行nop， 我问题是185行是开mmu，187 188行是等待生效，那186行是干嘛的？
执行后面只有两个周期 干访存和回写的事情，186行应该不是也做nop的吧  两个nop够了， 那他是干啥的？

smalloc

不明觉厉，猜测先写后读，是不是为了那啥序的....？

duanius

回复 4# smalloc
不理解 需要先写后读么？
手头没合适环境，不然杠掉试试


   

xs3c

duanius 发表于 2013-06-24 14:06
回复 4# smalloc
不理解 需要先写后读么？
手头没合适环境，不然杠掉试试

可能是方式乱序，后面的指令就是开mmu，CPU如果乱序的花，开Mmu的指令先执行了会有问题，通过软件再读来保证指令顺序执行。

duanius

回复 6# xs3c


    听上去感觉有些道理，但高版本的kernel这里是用isb做执行顺序的控制的，如果arm核版本高的话

xs3c

回复 7# duanius
这个你要具体看arm ISB指令的作用，我搜了一下：

ISB：指令同步和PowerPC的isync类似

so 看来isb和ppc的isync是一样的作用的，那就是为了指令同步。可能老版本的arm没有这类指令毕竟arm开始算是简单的。