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....
无标题
docker学习笔记系列 1. 01-Docker开发环境容器化：从基本概念到Ubuntu20 (个人博客链接) 2. 02-大型SDK开发镜像工程化：BuildKit、Buildx与项目脚本 (个人博客链接) (CSDN链接) 3. 03-交叉编译开发容器故障排查：从CMakeCache到目标库链接 (个人博客链接) (CSDN链接) 4. 04-Docker常用语法与命令：CLI、Dockerfile与Compose速查 (个人博客链接) (CSDN链接) 5. 05-Docker开发镜像跨主机迁移：从Ubuntu20 (个人博客链接) 6. 06-Docker开发环境到底要交付什么：镜像、源码与运行脚本 (个人博客链接) (CSDN链接) 7. 07-大型Docker镜像导出导入工程化：可靠性、磁盘与压缩 (个人博客链接) 8. 08-Docker29与containerd-image-store：镜像为什么会保存两种形态 (个人博客链接) 9. 09-大型Docker开发镜像磁盘排查：containerd、缓存与容量规划 (个人博客链接)
05-Docker开发镜像跨主机迁移：从Ubuntu20
Docker 开发镜像跨主机迁移：从 Ubuntu 20.04 到 24.04 摘要：说明如何把已验证的 Ubuntu 20.04 开发镜像迁移到 Ubuntu 24.04，并逐层验证 Docker、镜像、源码挂载和真实构建。 @[toc]旧开发机长期使用 Ubuntu 20.04，交叉编译 SDK、CMake 和各种依赖已经调通；新机器升级到 Ubuntu 24.04 后，最稳妥的做法往往不是重装整套依赖，而是继续运行已经验证过的开发镜像。 1. 宿主机升级，不等于容器也升级假设我们已经有一张镜像： 1cross-dev:20.04 它内部包含： 123456Ubuntu 20.04 用户空间Yocto SDK交叉编译器CMake / Make / Python代码生成工具entrypoint 把它迁移到 Ubuntu 24.04 后，结构是： 123456flowchart TB Host["Ubuntu 24.04 宿主机"] --> Engine["Docker Engine"] Engine --&g...
06-Docker开发环境到底要交付什么：镜像、源码与运行脚本
Docker 开发环境到底要交付什么：镜像、源码与运行脚本 摘要：从团队交付角度区分 Docker 镜像、bind mount 源码、entrypoint、Compose 和 dev.sh，明确哪些需要随镜像一起交给使用者。 @[toc]开发镜像自己能运行以后，下一个问题往往不是“怎么构建”，而是： 我要把这套环境给另一个开发者，他到底需要拿到哪些文件？ 最容易产生误解的是 entrypoint.sh、compose.yaml 和 dev.sh。 它们看起来都和“启动容器”有关，但所处层次完全不同。 1. 先把开发环境分成三层可以先用一张图建立边界： 123456flowchart TB User["开发者"] --> Dev["dev.sh"] Dev --> Compose["compose.yaml / docker run 参数"] Compose --> Image["Docker Image"] Image --> Entry[&...
08-Docker29与containerd-image-store：镜像为什么会保存两种形态
Docker 29 与 containerd image store：镜像为什么会保存两种形态 摘要：从 content store 与 snapshotter 两个角色解释 Docker Engine 29 的 containerd image store，以及大型镜像为什么比传统 overlay2 更占磁盘。 @[toc] 把一个大型开发镜像迁移到新的 Ubuntu 主机后，有时会看到一个很反直觉的结果： 12镜像内容大约 27 GiBDocker 相关磁盘却接近 50 GiB 如果新机器使用 Docker Engine 29+ 的全新安装，这个现象很可能与 containerd image store 有关。 Docker 官方当前文档明确说明：Docker Engine 29.0 及以后版本的全新安装，默认使用 containerd image store；从较早版本升级的系统则可能继续使用传统 graph driver。 1. 先确认当前后端Docker 官方提供的检查命令是： 1docker info -f '{{ .Drive...
07-大型Docker镜像导出导入工程化：可靠性、磁盘与压缩
大型 Docker 镜像导出导入工程化：可靠性、磁盘与压缩 摘要：分析二十多 GiB Docker 镜像在 save/load、临时 TAR、流式压缩、SHA256 和 zstd 之间的工程取舍，并给出更省磁盘的脚本结构。 @[toc]普通镜像只有几百 MB 时，docker save 和 docker load 很少让人关心磁盘峰值。 但开发镜像如果包含完整 Yocto SDK，规模达到二十多 GiB，导出本身就会变成一个值得设计的流程。 真正的问题不再只是： 1怎么导出？ 而是： 12345失败时会不会留下假成功文件？Ctrl+C 会不会留下几十 GiB 垃圾？临时 TAR 会占多少磁盘？压缩包是否需要先解压才能 docker load？如何校验传输完整性？ 1. save/load 的基本数据流导出： 1docker save -o cross-dev.tar cross-dev:20.04 导入： 1docker load -i cross-dev.tar 可以理解成： 12345Docker image ↓ docker save...
09-大型Docker开发镜像磁盘排查：containerd、缓存与容量规划
大型 Docker 开发镜像磁盘排查：containerd、缓存与容量规划 摘要：给出大型开发镜像的磁盘排查顺序，区分 containerd 镜像数据、snapshot、BuildKit cache、导出归档和源码构建输出。 @[toc] 当一个二十多 GiB 的开发镜像运行在 Docker Engine 29+ 新主机上时，磁盘问题往往比容器运行问题更早出现。 例如根分区只有约 80 GiB，却同时存在： 123456大型开发镜像containerd contentunpacked snapshotBuildKit cache源码 build 输出镜像导出归档 这时如果只看到： 1/dev/sdaX 90% 然后立刻运行 docker system prune -a，很容易删掉重新构建代价很高的开发镜像。 更好的方式是先回答： 空间到底被哪一类数据占用了？ 1. 第一层先看文件系统1df -h / 它回答的是： 1整个根文件系统还剩多少空间？ 它不会告诉你 Docker 哪个对象在占空间。 如果镜像归档放在其他分区，还要分别看： 1df -h /path/t...
01-Docker开发环境容器化：从基本概念到Ubuntu20
Docker 开发环境容器化：从基本概念到 Ubuntu 20.04 安装排查 摘要：从 Image、Container、Dockerfile 和挂载建立 Docker 心智模型，并结合 Ubuntu 20.04 的安装冲突说明为什么要把旧开发环境容器化。 @[toc]学习 Docker 最容易走偏的方式，是先背几十条命令，再去想这些命令解决什么问题。对于开发环境容器化，更合理的顺序正好相反：先明确工程为什么需要 Docker，再理解 Image、Container、Dockerfile、挂载和权限这些概念，最后才把命令放进实际场景。 本文从一个典型的嵌入式交叉编译环境出发：旧工程长期依赖 Ubuntu 20.04、厂商 Yocto SDK、固定 CMake、代码生成工具和若干宿主机软件。旧机器能稳定构建，但一旦换电脑、升级系统或让其他开发者接手，就很难准确复刻环境。 Docker 在这里的目标不是“把 Linux 再装一遍”，而是： 把构建环境固定成可重复生成的镜像，把日常修改的源码继续留在宿主机。 1. 为什么开发环境值得容器化传统开发机往往随着项目迭代逐渐变成这样...
02-大型SDK开发镜像工程化：BuildKit、Buildx与项目脚本
大型 SDK 开发镜像工程化：BuildKit、Buildx 与项目脚本 摘要：以约 25 GiB 的交叉编译 SDK 为例，解释 BuildKit、Buildx、named context、镜像层，以及 Dockerfile、Compose 和配套脚本怎样组成完整开发环境。 @[toc] 普通 Docker 教程经常从一个几十 MB 的源码目录开始：写 Dockerfile、COPY . .、执行 docker build，几秒钟就能看到结果。但真实嵌入式开发环境可能完全不是这个规模。 假设已有一套厂商 Yocto SDK，展开后约 25 GiB，还需要固定版本的 CMake、host 侧代码生成工具以及一套 UID/GID 兼容逻辑。此时问题已经从“会不会写 Dockerfile”变成了： 25 GiB SDK 怎样进入 Image； 怎样避免为了构建镜像再制造一个巨大的 SDK 压缩包； BuildKit 和 Buildx 分别负责什么； 为什么使用额外 build context； 为什么源码不和 SDK 一起做进 Image； 为什么需要 entry...
03-交叉编译开发容器故障排查：从CMakeCache到目标库链接
交叉编译开发容器故障排查：从 CMakeCache 到目标库链接 摘要：按真实首次失败点复盘旧 CMakeCache、host/target Thrift、SDK 权限、编译参数冲突和目标库链接，说明怎样沿证据链逐层收敛问题。 @[toc] Docker 能启动、交叉编译器能执行，只能证明环境最外层入口正常。历史 C/C++ 工程仍可能依次暴露旧 CMake 缓存、宿主工具、目标库、权限和编译参数策略。 这次排查最重要的原则是：围绕当前第一次失败收集证据，证明后再继续向后。 最终故障链可以概括为： 1234567flowchart TD Cache["旧 CMakeCache\n编译器路径属于旧 Host"] -->|干净 build tree| Compiler["交叉 GCC 正确识别"] Compiler --> Thrift["host Thrift 查找失败"] Thrift -->|确认 host generator| Header["...
