u-boot 学习笔记
u-boot 学习笔记 u-boot分类 1.1. api 1.1.1. api.md 1.2. arch 1.2.1. arm 1.2.1.1. arm.md 1.2.1.2. assembly.md 1.2.2. arch.md 1.3. boot 1.3.1. bootm.md 1.3.2. bootretry.md 1.3.3. bootz.md 1.3.4. image.md 1.4. cmd 1.4.1. cmd.md 1.5. common 1.5.1. autoboot.md 1.5.2. board.md 1.5.3. cli.md 1.5.4. command.md 1.5.5. console.md 1.5.6. dmalloc.md 1.5.7. event.md 1.5.8. export.md 1.5.9. log.md 1.5.10. main.md 1.6. dm 1.6.1. adc.md 1.6.2. button.md 1.6.3. clock.md 1.6.4. core.md 1.6.5. dts.md 1....
RT-Thread 学习笔记
RT-Thread 学习笔记 其他资料 1.1. fatfs 1.1.1. fatfs.md 2. ARM指针寄存器.md 3. CAN驱动.md 4. completion.md 5. condvar.md 6. dataqueue.md 7. DFS.md 8. fal.md 9. fatfs.md 10. FINSH模块.md 11. I2C驱动.md 12. IDLE线程.md 13. IPC.md 14. littlefs.md 15. map文件分析.md 16. pipe.md 17. PM电源管理.md 18. readme.md 19. ringblock.md 20. ringbuffer.md 21. romfs.md 22. RTC.md 23. RT-LINK.md 24. RTT系统初始化.md 25. SDMMC.md 26. SIGNAL.md 27. SPI驱动.md 28. tmpfs.md 29. ULOG.md 30. USB.md 31. waitqueue.md 32. 串口驱动.md 33. 调度.md 34. 工作队列...
游戏后台 CPU 占用高与全屏切换最小化问题排查指南
@[toc] 游戏后台 CPU 占用高与全屏切换最小化问题排查指南 本文整理两类常见现象的原因与优化方法： 后台运行时 CPU 占用率较高 全屏模式下切换程序时自动最小化 内容已做通用化处理，适用于多数基于现代 3D 引擎的 Windows 平台游戏。 解决后台运行时 CPU 占用率高理解高占用的原因现代 3D 游戏通常具备以下特征： 持续渲染画面（即使处于后台） 未锁帧时会尽可能输出更高帧率 持续进行物理计算、AI 逻辑、资源加载 引擎对多线程与 CPU 调度要求较高 当未限制帧率或未启用垂直同步时，游戏可能在后台仍以接近满载状态运行，导致 CPU 占用率持续偏高。 限制帧率以降低后台负载优先进行以下设置： 进入： 游戏设置 → 显示 / 图形设置 调整： 启用 V-Sync 或开启 帧率限制（FPS Cap） 建议设置为 60 FPS 或更低 这样可避免游戏在后台无限制渲染帧数。 关闭不必要的后台程序后台程序会与游戏争夺 CPU 资源，尤其包括： 浏览器 文件同步工具 即时通讯软件 云存储客户端 各类常驻启动项 操作步骤： 打开： 任务管...
VS Code Codex 登录失败（1455 端口占用）处理说明
@[toc] VS Code Codex 登录失败（1455 端口占用）处理说明 问题现象在 VS Code 中进行 Codex 登录时失败，提示错误信息类似： 1{"code":-32603,"message":"failed to start login server: Port 127.0.0.1:1455 is already in use"} 该错误表明：Codex 扩展在本机启动 OAuth 回调用的本地登录服务时，默认监听的 127.0.0.1:1455 端口已被其他进程占用，导致登录服务无法启动。 原因说明 Codex 登录流程依赖一个本地 HTTP 回调服务 默认端口为 1455 当该端口已被占用（常见于 VS Code 或相关子进程异常残留）时，登录流程会直接失败 错误与网络、防火墙或账号无关，属于本地端口冲突问题 适用环境 本机 Windows 本机直接运行 VS Code 非 Remote-SSH / WSL / Dev Container 场...
分卷压缩包损坏排查指南
@[toc] 分卷压缩包损坏排查指南 适用场景： 下载了 分卷压缩包（.zip + .z01/.z02/...、.part1.rar、.7z.001 等） 解压或测试时提示 Data Error / CRC failed / Unexpected end of archive 需要判断 是否只需重新下载某一个分卷 一、先确认分卷类型1. ZIP 分卷（常见、最容易混淆）文件结构示例： Game.zip（主文件） Game.z01 Game.z02 Game.z03 规则： 解压 / 测试 只能对 .zip 主文件进行 不要对 .z01 / .z02 单独操作 2. RAR 分卷文件结构示例： Game.part1.rar Game.part2.rar Game.part3.rar 入口文件：Game.part1.rar 3. 7z 分卷文件结构示例： Game.7z.001 Game.7z.002 Game.7z.003 入口文件：Game.7z.001 二、使用 NanaZip 进行初步测试（确认是否损坏）用途：判...
解决 `git cherry-pick` 引入大量新文件的问题
@[toc] 解决 git cherry-pick 引入大量新文件的问题1234567flowchart TD A[处于 cherry-pick 进行中?] -->|是| B[git cherry-pick --abort] A -->|否| C[评估目标] B --> C C --> D[仅需部分路径内容?] D -->|是| E[按路径取文件并单独提交] D -->|否| F[继续 cherry-pick 并清理不需要的新增/冲突] 问题域定义git cherry-pick 会把目标提交的变更整体应用到当前分支，当目标提交覆盖范围过大或包含不需要的目录时，常见结果是一次性引入大量新增文件、目录重排与删除。可观测症状包括：暂存区出现大量 new file，并伴随大量未合并冲突（例如 deleted by us 一类冲突）。影响范围通常覆盖整个 Git 工作树与索引状态，导致后续 --continue、路径恢复与清理操作相互阻塞。 机制分析 cherry-pick 以提交为单位应用补丁目标提交中包含的新增/删除&...
percpu-refcount
[TOC] lib/percpu-refcount.c percpu_ref（percpu 引用计数） 为高并发对象提供按 CPU 本地计数并可切换到原子模式的引用计数机制介绍percpu_ref 是内核通用引用计数基础设施，主体实现位于 lib/percpu-refcount.c，对外 API 与数据结构主要在 include/linux/percpu-refcount.h。它提供 struct percpu_ref 抽象：热路径用每 CPU 本地计数（this_cpu_add()/this_cpu_sub()）降低争用，进入销毁阶段后切换到全局原子计数并在归零时调用释放回调。内核态的接入点通常是“对象查找/获取引用”与“对象释放/销毁”两端：运行期用 percpu_ref_get()/percpu_ref_put() 或 percpu_ref_tryget_live()，销毁期用 percpu_ref_kill() / percpu_ref_kill_and_confirm()。用户态不会直接调用 percpu_ref，但常通过系...
Git文件状态显示异常的解决方案
Git索引一致性深度分析：基于Stat Dirty机制的“假脏”现象研究1. 问题背景与现象表征在分布式版本控制系统Git的日常操作中，工作区（Working Tree）与暂存区（Index/Stage）的一致性维护是确保版本历史准确性的基础。本研究针对一类特殊的索引状态异常进行深度分析：即git status报告文件处于修改状态（Modified），但git diff无法检索到任何实质性内容变更。 1.1 初始状态检测在项目维护过程中，系统处于main分支。通过执行状态检测指令，Git报告大量文件被标记为modified，同时存在少量的删除与未跟踪文件。 123456flowchart TD A[系统初始状态] --> B[执行 git status]; B --> C{检测索引与工作区}; C -->|发现元数据差异| D[标记文件为 Modified]; D --> E[输出状态报告]; E --> F[用户观测到大量变更]; 引用终端日志如下（路径已脱敏处理）： 123456789...
Ymodem协议帧填充机制与数据完整性校验的深度技术分析
@[toc] Ymodem协议帧填充机制与数据完整性校验的深度技术分析 本文旨在对Ymodem协议中数据帧末尾填充0x1A（SUB/CTRL-Z）的机制进行系统性分析。基于用户提供的技术排查结果与源码片段，本文将解析定长数据块传输的底层逻辑，并阐述在接收端如何利用元数据（Metadata）剔除无效填充字节，以确保文件传输的二进制一致性。 1. Ymodem协议的定长数据块架构Ymodem协议继承了Xmodem的定长分包传输特性。为了保持同步与校验的简便性，协议规定数据传输必须以固定的块大小进行。 1.1 数据帧类型与结构Ymodem支持两种标准数据帧类型，通过帧头字节进行标识： SOH (Start of Header, 0x01)：标识 128字节 数据载荷。 STX (Start of Text, 0x02)：标识 1024字节 数据载荷。 无论实际有效数据剩余多少，发送方必须填充数据区至上述固定长度，随后附加CRC校验码。 1.2 最后一帧的填充规则当文件大小不是128或1024的整数倍时，最后一帧必然存在无效空间。根据Ymodem/Xmode...
GCC
代码分析模板要求作用与实现要点 注释可读性策略：关键行注释必须解释“这一行做了什么、为什么要这么做、触发条件是什么、失败/成功会导致什么后果（引用计数/状态位/电源/等待条件）”，避免只写抽象标签（如“门控/关键路径”）而不说明具体含义。 注释排版策略：复杂条件表达式按行拆分后，需要对每一段条件分别就地注释，使读者能逐段理解分支成立原因。 术语约束：注释中不得出现“关键行”字样；应以“作用/原因/后果/约束”等表达替代。 来源与上下文策略：允许基于主线上下文核对与网页检索对齐，但正文不出现任何链接与可点击引用标记；若必须标注来源，只能在正文之外“对话附注”中用纯文本描述（不含 URL）。 平台关注：单核、无 MMU、ARMv7-M（STM32H750） 本段逻辑与单核/无MMU无直接差异，依赖底层 ops 与系统定时机制 请按以下模板为我分析并输出（中文、无链接）： 1) 标题： 用 ## 作为大标题 大标题只包含“本次代码片段里会出现 ### 小标题的函数名”（用空格分隔） 在函数名...