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. 工作队列...
解决 `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) 标题： 用 ## 作为大标题 大标题只包含“本次代码片段...
WIN11如何可以安装ISO
@[toc] WIN11如何可以安装ISO本文旨在对Windows 11环境下ISO镜像文件挂载与安装受阻的特定技术故障进行深度解析，并基于截至2025年9月23日的最终技术解决方案，阐述其操作流程与底层生效机制。本文将系统性地分析文件关联（File Association）与基于信誉的保护（Reputation-based Protection）对ISO文件系统挂载（Mounting）的影响。 1. 技术背景与解决方案综述在Windows 11的特定版本（特别是2025年下半年的更新周期中），用户在尝试打开或挂载ISO镜像文件时可能会遭遇系统静默拦截或无法识别的故障。根据提供的技术材料，该问题涉及操作系统对文件处理程序的默认设置以及Windows安全中心（Windows Security）的介入策略。 1.1 原始技术材料引用根据用户提供的截至 2025 年 9 月 23 日的解决方案，核心操作步骤如下： 截至 2025 年 9 月 23 日的真正解决方案 选择 ISO 文件并将默认应用程序设置为“Windows 资源管理器”。 打开 Windows 安全中心 -&g...
mmc_sdio
[toc] include/linux/mmc/sdio.hSDIO协议核心定义：命令、响应及寄存器映射本文件是Linux内核中用于支持SDIO（Secure Digital Input/Output）卡的核心头文件。它不包含可执行代码，而是完全由C预处理器宏（#define）构成。其核心功能是将SDIO物理规范中定义的命令码、寄存器地址、响应格式以及寄存器内的位域（bit fields）等数值，翻译成一组具有明确语义的符号常量。这为上层的SDIO核心逻辑和底层的主机控制器驱动提供了一个标准、可读且与具体数值无关的编程接口，是内核中所有SDIO相关操作的基础。 实现原理分析该文件的实现原理是典型的“规范到代码”的直接映射，是硬件编程中的一种基础实践。 符号化常量: 文件使用 #define 将SDIO规范中定义的魔法数字（Magic Numbers）替换为人类可读的名称。例如，将SDIO的“读写直接命令”的操作码52定义为SD_IO_RW_DIRECT。这样做极大地提高了代码的可读性和可维护性，当规范更新时，只需修改一处定义即可。 ...
mmc_sd
[TOC] drivers/mmc/core/sd_ops.c1234567891011121314int mmc_send_ext_addr(struct mmc_host *host, u32 addr){ struct mmc_command cmd = { .opcode = SD_ADDR_EXT, .arg = addr, .flags = MMC_RSP_R1 | MMC_CMD_AC, }; if (!mmc_card_ult_capacity(host->card)) return 0; return mmc_wait_for_cmd(host, &cmd, 0);} drivers/mmc/core/sd_uhs2.c SD UHS-II总线管理(SD UHS-II Bus Management) 实现UHS-II卡初始化与信号调整历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了支持 SD UHS-II（Ultra...
