Update README.md

README.md

@@ -4,7 +4,7 @@
 
 | 仓库名                    | 仓库描述                                                     | Github 地址                                                 | commit数量  （去年九月至今）                                  |
 | ------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- | ------------------------------------------------------------ |
-| code-debug                | 代码仓库                                                       | <https://github.com/chenzhiy2001/code-debug>                | 40（已去除零碎修改）                                                          |
+| code-debug                | 代码仓库                                                       | <https://github.com/chenzhiy2001/code-debug>                | 81（已去除零碎修改）                                                          |
 
 ### 本仓库结构
 
@@ -1288,14 +1288,19 @@ else if(action.type === DebuggerActions.check_if_kernel_to_user_border_yet){
 修改后将钩子断点设置在了 int ret = exec(path, argv)，可以正常返回下一进程名，至此，调试器可以正确调试xv6和ebpf。
 经验证后的 [配置文件](https://github.com/chenzhiy2001/code-debug/blob/master/installation%20and%20usage/xv6_launch.json)
 
-<span id="移植3"></span>
+<span id="移植2.5"></span>
+
 #### 适配性提升
 **\textbf{通过对xv6操作系统的适配，我们将调试器进一步完善，使之可兼容一个或多个边界的情况，完成了对c语言操作系统调试的扩充。今后，只需修改配置文件中用户自定义的部分，找到正确的边界，修改映射函数即可扩展可支持的语言，大大提高了灵活性和便捷性。}**
 
+<span id="硬件"></span>
+
 ## 支持在硬件上的调试
 
 昉·星光2 搭载四核64位RV64GC ISA的芯片平台（SoC），开源的昉·星光 2具有强大的软件适配性，官方适配Debian操作系统，同时通过社区合作适配各种Linux发行版，包括Ubuntu、OpenSUSE、OpenKylin、OpenEuler、Deepin等，及在这些操作系统上运行的各类软件。
 
+<span id="硬件1"></span>
+
 ### 框架搭建
 
 与硬件的连接主要借助jtag接口和openocd：前者一种硬件接口标准，用于芯片内部测试、系统仿真和调试，它允许开发者通过一组标准引脚（TCK, TMS, TDI, TDO, 以及可选的TRST）与芯片进行通信；后者是一个开源的调试器，它提供了对多种处理器和调试硬件的接口，包括JTAG，主要作用是作为一个中间件，它接收来自开发环境（如Eclipse, Visual Studio等）的调试命令，并通过JTAG等接口发送到目标硬件上执行。
@@ -1307,6 +1312,54 @@ else if(action.type === DebuggerActions.check_if_kernel_to_user_border_yet){
 
 简而言之，JTAG提供了硬件层面的连接和通信能力，而OpenOCD则提供了软件层面的控制和调试功能。两者结合使用，为嵌入式系统的开发和调试提供了强大的支持。
 
-### 硬件部署
+<span id="硬件2"></span>
+
+### 硬件部署及调试
 
 硬件连接及相关软件驱动详见：\hyperref[app:xv6]{附录D}。
+
+<span id="硬件2.1"></span>
+
+#### 调试方法
+1. 连接 JLink 和串口
+2. 打开调试器
+3. 按重置按钮三秒后松开
+4. 在任务管理器里关掉 tmux（如果有的话）
+5. 在 vscode 里开始调试（按 f5）
+
+<span id="硬件2.2"></span>
+
+#### 编译
+```
+make clean
+make hardcoded_ramdisk
+make
+```
+<span id="硬件2.3"></span>
+
+<span id="硬件3"></span>
+
+### 硬件适配
+目前实现：
+1. 内核态的单步调试
+2. 内核态到用户态的转换
+   
+开发板上有一个 qemu 虚拟机环境没用到的 dcsr 寄存器，里面 stepie 字段可以
+控制单步的时候是否打开中断。我们查看后发现 stepie 的值是 0，那么单步的时候中
+断是关闭的，这个时候去单步一个会导致中断的指令无效。但是这个开发板不支持调
+试器修改 csr，如果调用 openocd 的 set_reg 命令修改 dcsr 寄存器值，不仅寄存器的
+值不会改变，而且还会出现一个提示，说正在关闭 csr 寄存器的写入功能。
+
+我们又想到 ecall 之后不会立马切换页表，可以尝试把边界断点设置到 ecall 中断
+的中断处理函数上面。用户态断点保存在我们设定的断点组里面也不会丢，操作系统
+页表刷新以后再把断点加回来。在我们这个 os 中，ecall 的中断处理函数刚好在跳板
+页里，跳板页是不论内核态还是用户态都可以访问的，且不论内核态还是用户态，跳
+板页的虚拟地址都是一样的，所以这个思路是可行的。
+
+但是中断处理函数是写在 trampoline.S 这个汇编语言文件里的，GDB 无法根据
+内核符号表定位到这个汇编文件，GDB 根据内核符号表只能定位到 c 语言的源代码
+文件。奇怪的是，有一个用户态程序是直接由一个汇编代码文件编译生成，GDB 却
+可以定位到。
+
+经过尝试，我们发现把断点设置在把边界断点设置为 ecall 指令的前一个指令，
+就可以成功实现用户态到内核态的切换。至此，完成了调试器对硬件的适配。