蜗窝科技

@electrlife：Q1：内核开始阶段的代码是PIC的，copy到任何的位置都可以正确的执行 Q2：是的，不过elf binary使用的不准确，kernel elf binary不包括bss段以及之后的page table这样的特殊section，因此，准确的说，静态定义的page table只要能完成kernel image mapping（链接脚本中的_text符号到_end符号）就OK了 Q3：kernel image mapping一定是覆盖elf binary，不过不仅仅是elf binary，还有bss段和静态定义的页表区 Q4：一旦完成了地址映射（填充好了页表内容、打开了MMU），那么kernel已经在其虚拟地址空间中欢快运行（编译就是按照虚拟地址编的），你说的那些RW段的搬运，ZI段的初始化应该都是不需要的，BTW，我感觉你是搞cortex M系列处理器的，RW ZI这些术语不属于GNU GCC，应该是realview那套编译环境的 Q5：swapper process就是内核，swapper process地址空间就是内核地址空间。

@star：进程A在欢快的运行，发生了中断，陷入内核，完成处理之后，如果中断返回是回到进程A继续执行，那么你说的逻辑是通的，但是，中断返回一定是返回进程A的现场吗？

对于mmu不太熟，所以从elf角度思考且有些不解。 我理解： bootloaderr把image 搬运到物理内存里，此时mmu， cache等都是关闭的。此时的image是一个包含代码段数据段ZI段的binary。因此kernle首要任务是把此elf的binary中的各个section/segment映射到相应的虚拟空间上去。 Q1.这些虚拟的地址应该是在编译时就确定的，比如text section，在编译时就确认了其虚拟地址。 所以我们需要把这些虚拟地址映射到对应的物理地址上？ Q2.建立这些映射，需要建立其相应的页表，而页表也需要内存空间，依据您的描述，我的理解这此空间是位于elf binary 的bss段之后，其size是可以使其能够映射所有的elf binary所需的虚拟空间即可？ Q3.您文章中所提到的 kernel image mapping 是不是指的就是整个elf binary的映射（包括RO,RW,ZI,etc） ？ Q4.假设我们此时已经把整个elf binary (kernle image)映射到了相应的虚拟空间去，我们知道程序运行需要一些额外的环境的建立， 如RW段的搬运，ZI段的初始化，那其实我们已经映射其需要的虚拟地址上，是不是也就意味着这些动作就不需要执行了？ Q5. 依据您的描述我的理解在刚刚init时，物理空间布局如下，想了解下为何swapper process所需的空间有如此重要的地位？在这么早的阶段就需要静态的进行映射？ +------------------------------+ | | | elf binary (kernel image) | | | +------------------------------+ | page tables (elf binary) | +------------------------------+ | page tables (fixed mapping) | +------------------------------+ | page tables (swapper process)| +------------------------------+

Hi 博主， 我最近在看 svc handler，有一个问题不明白，用户模式进入 svc 模式的过程中，为什么需要保存 用户模式下的 sp 和lr，按照文档上的描述，用户模式下的 sp 和 lr 是banked 应该不需要保存才对。

@motou：多谢关注。由于太忙，要写的东西又比较杂，所以这一块一直没有机会更新。 我准备在x project做到显示的时候，再接着写这一系列的文章。

不错，2）后面就再没有新的了吗？

@kerneler：多谢鼓励，会坚持下去的:-)

@fanleung：不客气～～

@Layman：1. 你指的终极状态，都是所cpu core的状态，而在进入这个终极状态之前，做了什么事情，就是它们的区别。 2. 这个问题不太好回答啊，因为和具体的CPU有关，建议既可以在自己的CPU上测试一下。对比一下WFI前后的电流，应该可以看出来。

本来只是想大体浏览一下里面的文章，不打算留言的，但是几篇看下来几乎是一气呵成的，写的真的非常非常棒，忍不住赞美几句。希望能够坚持下去，你们写的真的非常不错