前往官网 
发布
X2000 眼图测试及USB 配置驱动能力
X2000 眼图测试及USB 配置驱动能力• 配置DWC控制器进入眼图测试模式 DCTL配置4~6位，为'100' Test_Packet mode模式。 DCTL寄存器基地址：0x13500804• x2000 USB Phy的IP厂商预留6bit用于调整眼图 3bit 调整幅度:通过调整参考电压来调整45Ω的HS终端电阻。 有助于补偿封装和电路板级寄生效应。 降低补偿电压,降低 ODT 阻抗。 3bit 调整斜率:通过调整参考电压来调整HS电流值。• 调整方法 usb phy寄存器映射到总线基地址： 0x10078000 调节眼图的寄存器地址： 0x10078060 描述： [4:2] 调整幅度 3’b000: 268mV (default) 3’b001: 262mV 3’b010: 250mV 3’b011: 237.5mV 3’b100: 275mV 3’b101: 281mV 3’b110: 293mV 3’b111: 300mV [7:5] 调节斜率 3’b000: 200mV (default) 3’b001: 225mV 3’b010: 250mV 3’b011: 175mV 3’b100: 400mV 3’b101: 425mV 3’b110: 450mV 3’b111: 375mV
X系列DDR频率配置简要说明
DDR频率配置简要说明1. 适用目的本文档用于指导客户完成两件事：1. 在 U-Boot 中配置 DDR 频率；2. 在系统启动后确认 DDR 频率是否真正生效。本文档尽量不依赖具体芯片平台，适合作为客户侧通用操作指引。2. 需要关注的配置项在 U-Boot 的 DDR 配置中，通常需要关注以下三个宏：• CONFIG_SYS_MPLL_FREQ：DDR 所使用的 PLL 源频率；• CONFIG_SYS_MEM_FREQ：系统期望的 DDR 工作频率；• CONFIG_：具体 DDR 颗粒参数表使用的频率,如CONFIG_X2600M_DDR2_MEM_FREQ(以下均以此示例参数进行介绍)• 注意：CONFIG_路径：u-boot/include/ddr/chips-v2/X2600N_DDR3_128M_COMPATIBLE_PARAM.h #ifndef CONFIG_X2600N_DDR3_MEM_FREQ #define CONFIG_X2600N_DDR3_MEM_FREQ CONFIG_SYS_MEM_FREQ #endif路径：u-boot/include/ddr/chips-v2/X2600M_DDR2_64M_COMPATIBLE_PARAM.h #ifndef CONFIG_X2600M_DDR2_MEM_FREQ #define CONFIG_X2600M_DDR2_MEM_FREQ CONFIG_SYS_MEM_FREQ #endif路径：u-boot/include/configs/x2600_ddr.h#ifdef CONFIG_DDR_TYPE_DDR2 #define CONFIG_X2600M_DDR2 #define CONFIG_X2600M_DDR2_MEM_FREQ 600000000 #define CONFIG_DDR2_KGD_CONFIG 0x1 #define CONFIG_DDR2_KGD_MR0_DLL_RST 0x1 #define CONFIG_DDR2_KGD_MR0_PD 0x0 #define CONFIG_DDR2_KGD_MR1_DLL_EN 0x0 #define CONFIG_DDR2_KGD_MR1_DIC 0x0 #define CONFIG_DDR2_KGD_MR1_RTT_NOM 0x0 #define CONFIG_DDR2_KGD_MR1_OCD 0x0 #define CONFIG_DDR2_KGD_MR2_DCC_EN 0x0#endif对于x2600N来说，只需要关注CONFIG_SYS_MEM_FREQ和CONFIG_SYS_MPLL_FREQ就好，而x2600M需要同时关注CONFIG_SYS_MEM_FREQ、CONFIG_SYS_MPLL_FREQ和如CONFIG_X2600M_DDR2_MEM_FREQ。对于单颗 DDR 的项目，建议按以下原则配置：• CONFIG_SYS_MEM_FREQ 与 CONFIG_X2600M_DDR2_MEM_FREQ 保持一致；• CONFIG_SYS_MPLL_FREQ 应为目标 DDR 频率的整数倍；• 同时还需满足平台代码允许的分频范围(1-16)。可简单理解为：CONFIG_SYS_MPLL_FREQ / CONFIG_SYS_MEM_FREQ = 整数CONFIG_SYS_MPLL_FREQ / CONFIG_X2600M_DDR2_MEM_FREQ = 整数示例：CONFIG_SYS_MPLL_FREQ = 1600000000CONFIG_SYS_MEM_FREQ = 320000000CONFIG_X2600M_DDR2_MEM_FREQ = 320000000此时：1600000000 / 320000000 = 5这是常见的合法配置方式。3. 在哪里修改 U-Boot 配置3.1 板级配置头文件通常位于：u-boot/include/configs/这里一般配置：• CONFIG_SYS_MPLL_FREQ• CONFIG_SYS_MEM_FREQ示例：#define CONFIG_SYS_MPLL_FREQ 1600000000#define CONFIG_SYS_MEM_FREQ 3200000003.2 DDR 颗粒配置头文件通常位于：u-boot/include/configs/这里一般配置具体颗粒频率，例如：#define CONFIG_X2600M_DDR2_MEM_FREQ 320000000建议将其与 CONFIG_SYS_MEM_FREQ 保持一致。4. 推荐操作步骤步骤 1：确定目标 DDR 频率例如希望 DDR 运行在 320MHz。步骤 2：修改板级头文件在 u-boot/include/configs/ 中设置：#define CONFIG_SYS_MPLL_FREQ 1600000000#define CONFIG_SYS_MEM_FREQ 320000000步骤 3：修改 DDR 颗粒头文件在 u-boot/include/configs/ 中设置，对于没有定义颗粒频率的，只需修改CONFIG_SYS_MEM_FREQ即可#define CONFIG_X2600M_DDR2_MEM_FREQ 320000000步骤 4：清理并重新编译 U-Boot修改 DDR 配置后，建议清理 U-Boot 中间产物再重新编译，避免旧参数残留导致配置未生效。5. 如何确认 DDR 频率是否生效仅修改头文件并不代表 DDR 频率一定已经生效，最终应以运行时结果为准。方法 1：查看启动串口日志很多平台在启动时会打印时钟信息，例如：[ 0.000000] x2600 Clock Power Management Unit init![ 0.000000] =========== x2600 clocks: =============[ 0.000000] apll = 1152000000 , mpll = 1600000000, ddr = 320000000其中：• ddr = 320000000表示当前 DDR 时钟频率约为 320MHz。方法 2：通过 clk 调试接口确认先挂载 debugfs：mount -t debugfs none /mnt再读取 DDR 时钟：cat /mnt/clk/gate_ddr/clk_rate示例输出：320000000表示当前 DDR 实际运行频率为 320MHz。6. 如何判断是否真正成功如果以下两项一致：1. 串口打印中的 ddr = xxx2. cat /mnt/clk/gate_ddr/clk_rate 的输出值则可认为当前 DDR 频率已经真正生效。例如：• 串口打印：ddr = 320000000• clk_rate 输出：320000000则说明 DDR 当前实际工作在 320MHz。7. FAQQ1：最终看哪个频率才算生效？答： 以运行时结果为准，即：• 串口日志中的 DDR 频率打印；• clk_rate 接口读出的 DDR 时钟值。Q2：为什么改了头文件，运行结果还是旧值？答： 常见原因有：• U-Boot 中间产物未清理；• DDR 参数文件未重新生成；• CONFIG_SYS_MEM_FREQ 与 CONFIG_ 未保持一致；• CONFIG_SYS_MPLL_FREQ 不是目标频率的整数倍。Q3：客户配置 DDR 频率时最简单的原则是什么？答： 直接按以下原则处理即可：• 目标频率先确定；• CONFIG_SYS_MEM_FREQ = 目标频率；• CONFIG_；• CONFIG_SYS_MPLL_FREQ = 目标频率 × 整数倍。8. 常用命令汇总挂载调试接口：mount -t debugfs none /mnt读取 DDR 时钟：cat /mnt/clk/gate_ddr/clk_rate9. 结论DDR 频率配置建议按以下方式处理：• 在 u-boot/include/configs/ 中配置：• CONFIG_SYS_MPLL_FREQ• CONFIG_SYS_MEM_FREQ• 在 u-boot/include/configs/ 中配置：• CONFIG_• 保证 CONFIG_SYS_MPLL_FREQ 是目标 DDR 频率的整数倍；• 保证 CONFIG_SYS_MEM_FREQ 与颗粒配置频率一致；• 启动后通过串口日志和 clk_rate 接口确认是否真正生效。
X系列 fb_stage 与 fb_stage_wip DPU 差异及升级说明
fb_stage 与 fb_stage_wip DPU 差异及升级说明1. 文档目的本文用于介绍kernel5.10在从2025.04更新到2026.01之后，即dpu使用的目录由fb_stage变为fb_stage_wip之后，DPU 显示主链路获得的能力、稳定性和使用收益，供客户评估后续软件升级。 对比目录： kernel/kernel-5.10/module_drivers/drivers/video/fbdev/ingenic/fb_stage kernel/kernel-5.10/module_drivers/drivers/video/fbdev/ingenic/fb_stage_wip2. 总体结论fb_stage_wip 对 DPU Composer/RDMA 的提交和完成链路进行了系统性增强。 相对 fb_stage，fb_stage_wip 的核心提升是：将原先偏“当前配置后立即启动”的控制方式，扩展为“图层更新请求 -> frame descriptor 队列 -> DPU 中断完成回收 -> 下一帧安全提交”的调度模型；同时补足 DMMU/TLB 映射、DMA descriptor 生命周期、刷新等待、旋转联动和用户态控制接口。 因此，fb_stage_wip 更适合持续刷帧、多图层、Composer 叠加、RDMA/Writeback、动态旋转及复杂 buffer 切换场景。fb_stage 后续不再维护；客户如需持续获得 DPU 主链路的功能完善与问题修正，应以升级至 fb_stage_wip 为主。3. 框架差异3.1 fb_stage：基础直接控制模型fb_stage 已具备基础 framebuffer、RDMA、Composer、DMMU/TLB 和 rotator 控制能力，但主流程更接近： 应用/Framebuffer 提交 layer 配置 -> 设置 frame/layer descriptor -> 启动或切换 DPU -> 由基础中断完成显示状态维护 该模型适合单 framebuffer、固定图层配置、较简单的显示切换。多图层独立更新、硬件仍在读取旧 descriptor 时的软件更新保护、以及不同输出通路之间的切换控制相对有限。3.2 fb_stage_wip：队列化的 Composer/RDMA 调度模型fb_stage_wip 将 Composer 提交链路拆分为请求、描述符、硬件完成三个阶段： 应用/Framebuffer 更新某个 layer -> 记录该 layer 的更新请求 -> 比较新旧配置，仅更新必要的 frame/layer descriptor -> 将 descriptor 加入 DPU 使用队列 -> DPU 在 EOD/EOW/EOC/SOC 等中断节点推进状态 -> 已完成 descriptor 回收到可复用队列 主要新增的内部管理对象包括： • 每图层请求队列：独立缓存各 layer 的待提交更新； • comp_desc_queued_list 与 comp_desc_done_list：区分“硬件正在使用”和“软件可复用”的 frame descriptor； • 新旧 comp_setup_info 比较：避免每次提交均无差别重建全部配置； • rdma_next_frame、rdma_changed、display_end 等状态：把 RDMA 切帧与 DPU 完成时序关联起来； • wait queue、completion 和 refresh/vblank 状态：为提交、写回完成、图层安全更新提供同步点。 该变化的直接收益是：软件不会轻易改写硬件仍在读取的 descriptor 或 buffer 对应配置，DPU 在多帧连续更新时的时序更可控。4. 面向 DPU 的主要优化 以下列出对 DPU 使用价值较大的改动。 优化方向fb_stagefb_stage_wip 的增强 对实际使用的价值 Composer descriptor 管理 以直接 setup/启动为主 增加 queued/done descriptor 队列和回收机制 降低连续提交时 descriptor 被提前改写的风险 多 layer 更新 更新路径较集中，缺少完整的逐 layer 请求调度 每个 layer 维护请求队列，按帧聚合提交 图层可独立刷新，更适合 UI、视频、OSD 等组合显示 配置变更处理 容易重复建立较多配置 比较新旧 comp_setup_info 和 layer 配置 减少无必要的 descriptor 更新，提交行为更可控 DPU 中断驱动 基础 IRQ 状态维护 增加 EOD、EOW、EOC、SOC 等事件的细化处理 把“何时显示结束、何时写回结束、何时可继续提交”明确化 RDMA 切帧 基础 frame change/start/stop 增加 RDMA 等待 vblank、下一帧状态及与 Composer 输出联动 连续刷新或间接输出时，降低切换时序不稳的概率 输出通路 基础 direct out/writeback 扩展 Composer -> RDMA、Composer -> Rotator 等组合通路 支持合成、写回、旋转、上屏之间的完整硬件链路 DMMU/TLB 具备基础 DMMU/TLB 支持 在 Composer 提交前增加 DMMU 映射流程，并结合 TLB/cache 同步 外部 buffer 或 TLB 图层的地址映射和数据可见性更完整 cache/DMA 同步 基础 flush 路径 按 TLB 图层和 cacheable framebuffer 路径分别处理同步 降低 CPU 写入后 DPU 取到旧数据的风险 descriptor DMA 内存 部分 descriptor 路径使用普通内存再取物理地址 RDMA/Composer descriptor 使用 DMA coherent 分配并初始化 更符合 DPU 硬件直接读取 descriptor 的 DMA 使用模型 用户态提交同步 基础 framebuffer 切换 增加 wait done、wait layer vsync、force update、render lock 等接口 应用可在相对安全的时机更新/提交图层，降低竞争与撕裂风险 动态旋转 有 rotator 基础控制 将目标旋转角度、layer angle、完成同步接入 Composer/DPU 通路 横竖屏和动态角度切换更容易与当前显示帧衔接 framebuffer 内存布局 基础按分辨率计算 framebuffer 大小与行长度 旋转场景下按 rotator 对齐要求计算 line length 与 frame 空间 90/270 度场景下 stride/内存布局更匹配硬件要求5. 关键能力说明5.1 描述符队列和完成回收fb_stage_wip 为 Composer descriptor 增加“空闲、已排队、已完成”的管理方式。软件提交新的图层组合时，优先从可用 descriptor 中构建新帧；DPU 硬件执行期间，该 descriptor 保持在 queued 状态；收到对应完成事件后才进入 done/可复用状态。 适用价值： • 连续刷新时，避免软件覆盖硬件正在读取的 frame/layer descriptor； • 多 layer 在不同时间更新时，能够聚合成完整帧后再提交； • DPU 忙时可通过队列和等待机制协调提交，而不是依赖上层自行猜测硬件状态。5.2 DPU 中断状态细化 WIP 对 DPU 的 EOD、EOW、EOC、SOC 等事件增加了单独处理逻辑，并用这些事件推进 descriptor、RDMA 和图层更新状态。 可将其理解为： EOD/EOW 等硬件事件到来 -> 标记当前帧/写回/图层状态完成 -> 唤醒等待者或回收 descriptor -> 在合适时机链接下一批已排队 descriptor 这对“上一帧尚未结束、下一帧已经到来”的高频刷新场景尤其重要。5.3 DMMU/TLB、cache 与 DMA 一致性处理 WIP 在 Composer 调用链中增加 DMMU 映射入口；提交前根据图层 tlb_en 与 framebuffer 的缓存属性执行相应同步。其目标不是单纯增加一次 cache flush，而是保证： CPU 写入图层数据 / 更新地址 -> 地址映射有效 -> 必要的数据同步完成 -> DPU 再读取 descriptor 和像素数据 该能力对下列 buffer 更有意义： • 启用 TLB/DMMU 的用户 buffer； • RGB 与 NV12/NV21 等不同格式混合的图层； • CPU、视频模块或其他 DMA 设备生产、DPU 消费的图像 buffer； • cacheable framebuffer 配置。5.4 Composer、RDMA、Rotator 的组合输出 WIP 按使用场景选择 Composer 输出模式： COMP_DIRECT_OUT Composer 直接上屏 COMP_WRITE_BACK Composer 合成结果写回内存 COMP_WRITE_BACK_2_RDMA Composer 写回后由 RDMA 上屏 COMP_WRITE_BACK_2_ROTATOR Composer 写回后进入 rotator 这使 DPU 可以按需求搭建“多图层合成 -> 写回 -> 旋转/上屏”的通路，而不局限于单一直接显示。5.5 动态旋转与 framebuffer 对齐 WIP 将 rot_angle_set（请求的目标角度）与实际 DPU/rotator 工作状态结合，并增加 layer 角度及完成等待处理。对于 90 度和 270 度场景，还在 framebuffer 分配、line_length 和旋转对齐尺寸上做了适配。 实际含义：动态横竖屏切换不应只修改一个角度寄存器；framebuffer 的行长度、有效宽高和硬件输出路径也必须与旋转要求匹配。WIP 已在驱动主链路中补充相关处理，降低应用仅切角度造成内存布局不匹配的风险。5.6 对外控制接口完善 WIP 扩展了与 framebuffer/Composer 相关的控制能力，包括旋转角度设置/获取、指定 layer 等待 vsync、等待合成完成、强制更新、render lock/unlock 等。 这些接口的目的不是增加普通显示功能，而是让上层在以下时刻有明确同步手段： • 图层内容写完后再交给 DPU； • 切换 buffer 前等待当前 layer 到达安全位置； • Writeback 场景等待硬件合成完成后再使用输出 buffer； • 动态旋转或图层参数改变时，减少与正在执行的帧发生竞争。6. 建议升级到 fb_stage_wip 的具体使用场景场景 1：双缓冲/多缓冲 UI 连续刷新 典型流程：应用持续绘制下一帧 framebuffer，并在 yoffset 或图层地址切换后上屏。 升级收益：WIP 的 RDMA 切帧状态、vblank 等待和 descriptor 队列更适合连续提交，可减少“软件快速切换、硬件尚未消费完成”的时序风险。场景 2：多图层叠加显示 典型组合：背景 UI + 图标/OSD + 视频/YUV 图层；不同图层的更新频率不同。 升级收益：WIP 支持按 layer 缓存更新请求并聚合提交，配合 layer 的 format、stride、alpha、z-order 等配置，更适合让 DPU 硬件完成叠加，减少每次仅更新一个 layer 时影响其他 layer 的可能性。场景 3：NV12/NV21 视频或相机 buffer 与 UI 合成 典型流程：视频模块提供 YUV buffer，UI 模块提供 RGB/ARGB buffer，DPU Composer 做硬件合成。 升级收益：WIP 对 layer stride、UV 地址、DMMU/TLB 映射和提交同步的处理更完整，适合多格式 buffer 进入同一 DPU 合成通路。场景 3：Composer 写回后再上屏 典型流程：多个图层先合成为一张中间图，再通过 RDMA 读取该结果送屏。 升级收益：WIP 明确支持 COMP_WRITE_BACK_2_RDMA，并用写回结束/descriptor 队列协调 buffer 生命周期，适合需要中间合成结果的显示链路。场景 5：开机后动态横竖屏切换 典型流程：设备运行中在 0、90、180、270 度之间切换，且界面/图层持续刷新。 升级收益：WIP 的 rotator、Composer 输出模式、framebuffer 对齐和 layer angle 联动更完整。对于 90/270 度，还能避免只修改角度而未同步处理 line length 与 frame 空间的典型问题。场景 6：需要稳定定位 DPU 刷新问题 典型问题：偶现花屏、闪烁、切帧不同步、图层显示旧内容、合成结果未完成即被使用。 升级收益：WIP 的中断状态、descriptor 队列、等待接口和更细的 DPU 控制状态，能够提供更清晰的问题定位基础；fb_stage 后续不维护时，新问题也更难获得主线修正。7. 不升级的风险 保留 fb_stage 不代表基础显示一定不可用；对于单 framebuffer、固定分辨率、低频更新的简单产品，现有版本可能仍可满足使用。但需要接受以下边界和风险： 风险类别 不升级时的影响 后续维护fb_stage 后续不维护，DPU 主链路的新修正与能力完善不会继续回补 连续刷新时序 缺少 WIP 的 descriptor 队列和完整事件推进，复杂连续提交场景更依赖上层时序控制 多 layer 场景 图层独立更新、同步和回收能力较弱，后续扩展 UI/视频/OSD 混合时成本更高 Writeback/间接输出 Composer -> RDMA/Rotator 等组合通路不如 WIP 完整，复杂显示链路需要自行补充适配 TLB/DMMU buffer 对外部 buffer、映射和 cache 同步的使用约束更严格，错误更难通过基础框架规避 动态旋转 横竖屏频繁切换时，角度、stride、framebuffer 对齐和通路切换更容易需要额外定制 问题定位 缺少更完整的状态/等待/队列基础，偶现刷新问题定位和复现成本更高8. 升级建议8.1 推荐策略 建议后续 DPU 功能开发和客户项目统一以 fb_stage_wip 为基础，不建议在 fb_stage 上继续叠加新的复杂显示功能。特别是涉及 Composer、RDMA、动态旋转、多图层或 TLB/DMMU 的项目，应优先升级。8.2 升级验证重点 升级并不是只替换目录；应结合实际产品完成以下验证： 1. 基础显示：冷启动、热重启、待机恢复、背光开关后是否正常上屏。 2. RDMA：双/多缓冲连续切换，验证无明显错帧、闪烁和停帧。 3. Composer：RGB/ARGB/YUV 图层叠加、alpha、z-order、crop、stride 是否符合预期。 4. TLB/DMMU：使用外部/用户图像 buffer 时验证地址映射及 cache 同步正确性。 5. Writeback：确认写回完成后才读取或复用输出 buffer。 6. 旋转：分别验证 0/90/180/270 度，尤其检查 90/270 度的源图宽高、stride、framebuffer 行长度和显示方向。 7. 压力测试：高频提交、频繁切图层、长时间运行和异常恢复场景。9. 最终建议fb_stage_wip 的价值在于增强整个 DPU 的可控性，而不仅是解决单一显示问题：它将图层更新、descriptor 生命周期、DPU 中断、RDMA 切帧、Writeback、Rotator、TLB/DMMU 和用户态同步接口串成更完整的控制链路。 对于只需维持当前简单显示功能的产品，fb_stage 可以作为存量方案；对于后续需要维护、扩展或交付复杂显示能力的客户，应明确选择 fb_stage_wip 作为后续升级基线。由于 fb_stage 已停止维护，继续基于旧目录开发会逐步增加功能补丁分散、问题回归和维护成本。
libbare-cpu 介绍
libbare-cpu 介绍 libbare-cpu 是Ingenic为其MCU提供的一个底层硬件库，旨在提供不依依赖于操作系统的裸机环境，其结构简单，直接面对硬件控制器寄存器编程，能够实现误操作系统的业务逻辑。同时libbare-cpu提供了基于 freertos/alios/rthtread的porting文件，方便适配到rtos系统，满足对操作系统有需求的用户。 配合Ingenic提供的JTAG调试器，支持使用VSCode 在线调试代码。 目前主要支持芯片 • X16XX • X26XX系统结构源码目录结构 ├── cpu │ ├── core # CPU 体系结构相关，主要是mips xburst系列. │ └── soc-x16xx # soc-x16xx 系列芯片寄存器定义 │ └── soc-x2000 # soc-x2000 系列芯片寄存器定义<X2000/X2000E/X2100/X2000H> ├── Doxyfile # 用于生成API文档 ├── drivers │ ├── bsp # 开发板级相关的驱动，例如：开发板上的camera/lcd驱动等，封装成库文件 │ │ ├── common │ │ ├── x16xx-halley6 # [chipname]-[devboard] │ │ └── x2000-halley5 │ ├── core # mips架构,用于适配不同系统的文件，支持裸系统bare/alios/rtthread/freertos. │ │ ├── alios │ │ ├── bare │ │ ├── freertos │ │ └── rtthread │ ├── core-riscv # riscv架构,用于适配不同系统的文件，支持裸系统bare/alios/rtthread/freertos. │ └── drivers-x16xx # soc-x16xx 对应的hal 寄存器驱动 │ ├── drivers-x2000 # soc-x2000 对应的hal 寄存器驱动 │ ├── drivers-x2600 # soc-x2600 对应的hal 寄存器驱动 ├── lib │ ├── gcc # gcc 库 │ └── libc | ├── minimal # 最小的C库实现，不支持浮点 │ └── newlib # 移植的newlibc，支持浮点和软浮点 ├── Middlewares # 中间组件 │ ├── Third_Party │ └── X16XX_USB_Device_Library ├── projects # 工程示例 │ ├── x16xx-halley6 # 针对 x16xx系列芯片 halley6开发板的示例程序. │ │ ├── Apps # 实现某些有特色功能的应用程序，例如：音频播放器，camera recorder 等等。 │ │ ├── Demos # 结合市场需求，开发的具有特色的产品推广的 demo. │ │ ├── Examples # 针对芯片控制器编写的使用示例，例如：串口，SPI，I2C 等等. │ │ └── Templates # 工程模板，可以复制Templates到其他文件夹，进行工程创建. │ ├── x2000-halley5 # 针对 x2000系列芯片 halley5开发板的示例程序. │ │ ├── Apps # 实现某些有特色功能的应用程序，例如：音频播放器，camera recorder 等等。 │ │ ├── Demos # 结合市场需求，开发的具有特色的产品推广的 demo. │ │ ├── Examples # 针对芯片控制器编写的使用示例，例如：串口，SPI，I2C 等等. │ │ └── Templates # 工程模板，可以复制Templates到其他文件夹，进行工程创建. │ └── x2660-halley # 针对 x2600系列芯片 halley开发板的示例程序. 支持mips/riscv体系结构的程序. │ ├── Apps │ ├── Demos │ ├── Examples │ └── Templates ├── README.md └── tools ├── astyle.sh ├── create_project.py ├── ld.lds # 系统的链接脚本 ├── proj ├── vscode_template ├── dev-tools | ├── Windows # windows 开发工相关软件安装包 | └── Linux # Linux 开发工具相关软件 └── windowslib 目录说明 ├── gcc │ ├── fp64 │ ├── include │ └── sof └── libc ├── minimal │ └── include └── newlib ├── include └── lib ├── fp64 └── sof 主要包含 • gcc libgcc 使用说明 • libc-minimal • libc-newlib开发环境搭建工具链信息汇总 工具链名称 支持芯片系列 Linux下载链接 Windows下载链接 百度网盘链接 XBURST1 X1600系列ftp://ftp.ingenic.com.cn/Ingenic-MIPS-Toolchain/releases/ingenic-mips-toolchain-r5.1.6/mips-ingenic-xburst1-elf-tools-r5.1.6.tar.bz2ftp://ftp.ingenic.com.cn/Ingenic-MIPS-Toolchain/releases/ingenic-mips-toolchain-r5.1.6/mips-ingenic-xburst1-elf-tools-x86_64-w64.r5.1.6.zip链接 提取码: res3 XBURST2 X2000/X2600系列ftp://ftp.ingenic.com.cn/Ingenic-MIPS-Toolchain/releases/ingenic-mips-toolchain-r5.1.6/mips-ingenic-xburst2-elf-tools-r5.1.6.tar.bz2ftp://ftp.ingenic.com.cn/Ingenic-MIPS-Toolchain/releases/ingenic-mips-toolchain-r5.1.6/mips-ingenic-xburst2-elf-tools-x86_64-w64.r5.1.6.zip链接 提取码: 9g4f RISC-V V0 X2600系列(RISC-V小核)ftp://ftp.ingenic.com.cn/Ingenic-RISCV-Toolchain/Victory0-Series/releases/riscv-ingenic-victory0-series-toolchain-r1.0.1/riscv-ingenic-victory0-series-toolchain-r1.0.1.tar.bz2ftp://ftp.ingenic.com.cn/Ingenic-RISCV-Toolchain/Victory0-Series/releases/riscv-ingenic-victory0-series-toolchain-r1.0.0/riscv-ingenic-victory0-series-toolchain-win64-r1.0.0.tar.bz2链接 提取码: nz6i 注意: 如果ftp无法访问，请使用百度网盘链接进行下载。U-BOOT 下载 • git clone http://git1.ingenic.com.cn:8082/gerrit/bootloader/u-boot -b ingenic-master u-boot-ingenic-master烧录工具下载 平台 官方下载链接 替代下载方案（百度网盘） Linuxftp://ftp.ingenic.com.cn/DevSupport/Tools/USBBurner/cloner-latest-ubuntu.tar.gz Windowsftp://ftp.ingenic.com.cn/DevSupport/Tools/USBBurner/cloner-latest-windows.zip Linux & Windows链接 提取码: svwi 参考文档 tools 目录下包含必要的开发工具： tools ├── dev-tools │ ├── linux │ └── windows │ ├── adb │ ├── CMake │ └── mingw64 ├── ld.lds └── windows └── Windows开发环境搭建.md开发环境设置 • windows 开发环境搭建 • Linux 开发环境搭建使用方法 使用示例参考projects/template2.1 Linux 平台开发2.1.1 基于Makefile编译 $ make 会在build目录生成template.elf, template.bin文件.2.1.2 基于cmake构建 前提：确认cmake 版本 cmake-v3.23.1 ，可以使用最新的cmake版本。 $ mkdir build $ cd build $ cmake -DCMAKE_TOOLCHAIN_FILE=../mips-gcc-sde-elf.cmake .. $ make 会在build目录下生成template.elf，template.bin文件.2.1.3 基于vscode 集成开发环境 前提：确认cmake 版本 cmake-v3.23.1 ，可以使用最新的cmake版本。 注意：不要使用工具链的cmake。否则vscode 会报错。 流程如下： 1. vscode 打开工程 2. 选择cmake kits：cmake-kits "GCC for ingenic cross compile on Linux" 3. lunch(F5) 运行编译、调试 4. 选择状态栏,build， 进行代码编译.2.2 windows 平台开发 windows 开发需要安装相关的软件和系统环境变量配置，参考 Windows开发环境搭建手册2.2.1 基于vscode集成开发环境 流程如下: 1. vscode 打开创建好的工程文件夹，例如 projects/template 文件夹 2. 选择cmake-kits "GCC for ingenic cross compile on Windows" 3. lunch(F5) 运行编译、调试 4. 或者选择状态栏，build，仅编译. 说明: vscode 可以支持在线调试，也可以仅编译后，使用烧录工具烧到开发板运行2.2.2 基于命令行编译 前提： 系统必须安装msys - mingw64-make 工具. $ mkdir build $ cd build $ cmake -DCMAKE_TOOLCHAIN_FILE=../mips-gcc-sde-elf.cmake -G "MinGW Makefiles" ../ $ mingw32-make3. 程序烧录烧录配置 打开烧录工具，选择配置界面3.1 选择烧录配置 以x16xx系列芯片x1600e,halley6开发板为例. 1. 选择芯片平台"x1600" 2. 根据开发板配置选择板级。 开发板板载nand flash，选择"x1600e_sfc_nand_lpddr2_linux.cfg" 开发板板载nor flash，选择"x1600e_sfc_nor_lpddr2_linux.cfg"3.2 选择烧录镜像 运行裸机驱动程序需要烧录uboot和裸机程序 1. 选择uboot镜像, u-boot-with-spl.bin 注意:uboot镜像需要另外修改和编译，uboot需要将裸机程序引导在0x80600000地址进行启动，所以需要修改其boot command。 以halley6开发板为例，在Manhattan工程的u-boot目录，修改uboot板级配置文件( u-boot/include/configs/halley6.h )中boot command的定义, 根据板载flash类型进行区分： Nor flash: #define CONFIG_BOOTCOMMAND "sfcnor read 0x40000 0x600000 0x80600000;go 0x80600000" Nand flash: #define CONFIG_BOOTCOMMAND "sfcnand read 0x100000 0x800000 0x80600000;go 0x80600000" 修改保存之后，回到u-boot/目录，进行编译，同样根据板载flash类型进行区分： Nor flash: 执行make halley6_uImage_sfc_nor -j Nand flash: 执行make halley6_uImage_sfc_nand -j 编译成功之后，就会在该目录下生成u-boot-with-spl.bin镜像。 2. 选择之前编译完成的裸机驱动程序(二进制*.bin文件，这里以template.bin为例) 到这里烧录配置完成，点击“保存”按钮，保存配置, 回到初始界面后，点击“开始”按钮，开始烧录.3.3 spl 启动 raw driver 注：目前此启动模式暂时只针对x1600 nor flash panda 板。 该章节中采用的是 spl 启动 raw driver ，3.2 部分采用的是 u-boot 启动。3.3.1 uboot 编译 spl 打开 ubooot 程序在u-boot 目录下进行执行 make distclean;make panda_rtos_sfc_nor; 在 u-boot/spl 目录下生成 u-boot-spl-pad.bin ，烧录工具选择该文件位置以及选择之前编译完成的裸机驱动程序(二进制*.bin文件，这里以 template.bin 为例)，此时 spl 所占大小为 256K 烧录具体选择如下3.3.2 减少 spl 所占空间修改 注：与 3.3.1 选择一个即可 第一步：打开 uboot 源码目录输入,对应图片进行修改如下可作为参考最小 32k 大小 vim include/configs/panda.h 编译执行 make distclean;make panda_rtos_sfc_nor 此时烧录文件为 uboot /spl目录下 u-boot-spl-pad.bin 与编译出的template.bin文件 烧录工具也需要进行对应的修改，按照以下图片进行修改。 需要对 uboot 部分和 kernel部分都修改为与图片一致的数据3.4 详细参考资料 libbare 是裸机SDK， 对应Linux 的SDK 资料更加全面，其中部分开发流程可以参考Linux的开发资料。 • 烧录工具的详细使用 • uboot 开发和配置 芯片平台 资料名称 链接 X16XX 文档仓库X16XX开发手册 X26XX 文档仓库X2600开发手册4. 创建工程4.1 基于已有工程 可以在project目录下，找到一个合适的工程，复制到新的文件夹，进行以下修改 1. SDK_PATH 修改 修改工程目录CMakelists.txt 中SDK_PATH 到 libbare-cpu 根目录，可以是相对路径，也可以使用绝对路径. SDK_PATH = ../../ 2. 修改CMakelists.txt 工程名称 例如: Project(my_template) # Modified 3. 添加源文件 根据工程实际情况，添加需要编译的源文件 set(sources_SRCS # Modified ${SDK_PATH}/cpu/core/genex.S ${SDK_PATH}/cpu/core/spinlock.c ${SDK_PATH}/cpu/core/start.S ${SDK_PATH}/cpu/core/traps.c ${SDK_PATH}/cpu/soc-x16xx/interrupt.c ${SDK_PATH}/cpu/soc-x16xx/serial.c ${SDK_PATH}/cpu/soc-x16xx/startup.c ${SDK_PATH}/drivers/drivers-x16xx/src/x16xx_hal_def.c ${SDK_PATH}/lib/libc/minimal/ctype.c ${SDK_PATH}/lib/libc/minimal/div64.c ${SDK_PATH}/lib/libc/minimal/string.c ${SDK_PATH}/lib/libc/minimal/vsprintf.c main.c ) 4. 添加头文件路径 根据实际情况，添加需要包含的路径 include_directories( ${SDK_PATH}/lib/libc/minimal/include ${SDK_PATH}/drivers/drivers-x16xx/include ${SDK_PATH}/cpu/core/include ${SDK_PATH}/cpu/soc-x16xx/include ) 5. 添加库路径 link_directories( ${SDK_PATH}/lib/libc/newlib/lib/ ) 6. 添加链接的库选项 确保要链接的库在link_directories中定义 set(CMAKE_LD_FLAGS "${CPU_PARAMETERS}" -lm -lc -lgcc -lnosys)在线调试5 JDI调试5.1.准备调试环境 • JDI 调试环境搭建和使用5.2. 调试说明 按下键盘的F5或者Run菜单下的Start Debugging开始调试。等待代码编译并加载完成会出现如图所示界面。图中标注的序号代表不同的工作区域。各个区域含义如下。 1.表示目前处于debug菜单栏，显示各种调试相关的选项视图。 2.显示调试过程中的变量、数组、寄存器值。这些值会随着调试位置变化而动态变化。另外，鼠标放在结构体上也可以显示 3.调试控制区域。6个按钮从左到右依次是：执行到下一个断点（断点位置需手动添加）、执行到下一行、执行到函数体内、从函数体中执行出去、重新开始调试、结束调试。 4.在该区域可以手动添加断点。 5.函数的调用堆栈 6.添加的断点信息 注意6 开发板调试 使用配套的panda开发板通过添加打印的方式进行调试。
X系列芯片通用Q&A
Ingenic SoftWare Q&A通用平台问题环境搭建Q: 烧录工具的LOCK_LEVEL 的密码是什么？A: !@#编译问题Q: 虚拟机环境，编译sdk报下面的错误是什么原因？A: 虚拟机内存不够了，需要扩大虚拟机内存，如果是虚拟机分配的硬盘空间不够是报类似“no space” 的错误。Q: 编译时报错下方报错，如何解决？make[3]: mkimage：命令未找到A: pc 需要安装：sudo apt-get install uboot-mkimageQ: 编译时报"cmake not found" 错误，如何解决？A: manhatton buildroot 有个问题需要注意: buildroot 编译的时候会检查系统环境上有没有cmake ,如果有并且版本大于等于3.10 的时候就不会去编译host-cmake,这个时候会造成Build.mk 的cmake 编译出错(因为build 里面依赖与out 路径下面指定的cmake),解决方式,buildroot 直接选中host-cmake:Q: 在一个终端编译工程执行了source ,lunch 命令之后换了终端直接make 编译为什么报错？A: 在A 终端执行了source ,lunch 初始化了编译环境之后，这个编译环境只对当前的A 终端有效，新开的B 终端编译之前必须再次执行一遍source,lunch 的操作，只要这个终端不关（A,B 都是），就只执行一遍source,lunch 操作即可。Q: 在工程编译的时候遇到了下面的报错，如何解决？A: log 报错已经有了提示，kernel 源码目录不干净，应该是在kernel 的目录下面执行过单独编译的命令，生成了中间文件，这个时候在退到工程的主目录，执行工程编译kernel 的命令:make kernel 就会报上面截图的错误，解决方式，按照log 的提示进入kernel 目录下面执行:make mrproper 命令即可。启动报错Q: 系统启动出现下面的报错，是什么原因？A: 这个是reserve memory 的报错，需要看对应的板级设备树reserve memory 节点的配置。Q: nand flash 启动有 "oob error" 的错误打印是什么原因？[ 0.314481] ingenic-sfc 13440000.sfc: /home/Data/users/HSystem/X2000/ingenic-linux-kernel4.4.94-x2000_v12-v4.0-20200724/kernel-4.4.94/drivers/mtd/devices/ingenic_sfc_v2/ingenic_sfc_nand.c ingenic_sfcnand_read_oob 474 : spi nand read oob error ,ret= -77 [ 0.337547] Bad eraseblock 1210 at 0x000009740000 [ 0.417978] Creating 4 MTD partitions on "sfc_nand": [ 0.423119] 0x000000000000-0x000000100000 : "uboot" [ 0.428910] 0x000000100000-0x000000900000 : "kernel" [ 0.444706] 0x000000900000-0x00000c800000 : "rootfs" [ 0.460576] 0x00000c800000-0x000010000000 : "userdata"A: oob 是遇到了坏块,一定数量的oob 打印（不会增加）是正常的打印，由nand 的特性决定的，nand 有坏块处理，ecc检测及纠错机制。Q: 启动报下面的错误，该如何解决？A: 可以尝试降一下cpu 的频率或者检查下code 的电压。调试方法Q: 如何确认 camera 当前支持格式？A: 使用如下命令：v4l2-ctl -d /dev/video5 --list-formats-extQ: 如何查看某个程序占用的内存？A: 下面rss参数就是程序占用的内存：cat /proc//status ps -o pid,rss,commQ: 如何查看当前的 GPIO 状态？A: 通过以下命令查看：find . -name "dump_gpio" cat /sys/devices/platform/apb/10010000.pinctrl/dump_gpioQ: 如何查看系统的中断？A: 使用以下命令：cat /proc/interruptsQ: 为何烧录过程中串口没有打印？A: 烧录工具配置界面有修改串口配置，默认已经按照我们的开发板配置好，不用修改，如果硬件上改了串口，要按照实际的情况来配置串口：Q: emmc 烧录成功但是无法启动，如何查问题？A: 烧录工具有读flash数据存成文件的功能,多用于flash (nand ,emmc) 烧录完成之后不能正常启动原因分析。高频问题Q: 客户自己做的硬件，如何配合硬件修改debug 串口？A: 修改debug 口有如下的几个位置，下面以x2000 为例，其他芯片平台类似： * (1) uboot：*u-boot/include/configs/halley5.h84 #define CONFIG_SYS_UART_INDEX 3 /*默认是uart3,根据实际修改此处*/ 85 #define CONFIG_BAUDRATE 115200 173 #if (CONFIG_BOOTARGS_AUTO_MODIFY == 1) 174 #define BOOTARGS_COMMON LINUX_LOGLEVEL " console=ttyS3,115200 " /*默认是uart3,根据实际修改此处*/ 175 #else 176 #define BOOTARGS_COMMON LINUX_LOGLEVEL " console=ttyS3,115200 mem=128M@0x0 " /*默认是uart3,根据实际修改此处*/ 177 #endif(2) kernel：*kernel-4.4.94/arch/mips/boot/dts/ingenic/halley5_v30.dts101 &uart3 { 102 status = "okay"; 103 pinctrl-names = "default"; 104 pinctrl-0 = ; 105 }; 106 /*此处根据实际的uart口以及硬件io 来配置*/Q: pad的datatsheet里面列举了一些pad类型：施密特类型，加了上拉电阻的，加了下拉电阻的，OPEN DRAIN,请问根据什么依据来选择类型呢？请大神详细讲解一下呗？A: 根据实际需求，建议重点关注以下几点：reset 管脚建议使用施密特类型。输出管脚需根据驱动能力选择（如04,08.,12 等）。I/O 通常带三态，设计中应包含 in、out、out_oen。时钟通常使用专用 pad，一般为两个脚，可外接 crystal。模拟 pad 为特殊类型，需使用专门库。是否需要 pull-up / pull-down 电阻。封装与排布选择（inline 或 staggered）需按实际设计匹配。是否需要 5V tolerance。是否有特殊 ESD 要求。Q: 烧录镜像的时候出现下面报错是什么原因？怎么解决？A: 这个错误是烧录的镜像超过了文件系统分区导致的，可以通过裁剪文件使镜像变小解决此问题，也可以通过加大分区来解决问题（一般文件系统的分区后面还有一个data 分区，加大文件系统的分区空间意味着data 分区会相应的减小。）Q: 开发板开了adb 的服务，查看也有进程，但是pc 无法识别adb 设备？A: 执行以下命令：sudo adb kill-server sudo adb start-serverQ: 想要在烧录的阶段，把某个gpio 进行拉高或者拉低操作，具体应该怎么做？A: 比如，想要在烧录过程中讲pe16 这个pin 拉高，可以在烧录工具的gpio add 界面做下面的添加测试： 其中10000 改成0x10000 代表对应的是io 的位置bit。Q: 烧录阶段报下面的错误是什么原因？ extend policy manager register burner_x1000# magic=POLI magic=DBG magic=EFUS magic=POLI magic=SFC id_manufactory = ff, id_device cd id_manufactory = cd, id_device 70 ERROR!: don`t support this nand manufactory, please add nand driver, id_manufactory 0xcd id_device 0x70 ERR: sfc try id error! ERR: jz_sfc_nand_init error! cloner->ack = -5A: 当前的flash 型号不支持。Q: 今天发现连telnet时连不上，开机的时候telnetd是有的，占用23端口，我这边一连这个程序就退了，有什么需要增加的配置么？A: kernel 选中如下配置：驱动示例X2000 LCD 驱动参考MIPI DSI (4lane) 屏驱动参考：module_drivers/drivers/video/fbdev/ingenic/fb_stage/displays/panel-fw050.cMIPI DPI(rgb) 屏驱动参考：module_drivers/drivers/video/fbdev/ingenic/fb_stage/displays/panel-st7282.cMIPI DBI typeC (SPI 接口) 屏驱动参考：module_drivers/drivers/video/fbdev/ingenic/fb_stage/displays/panel-st7701s-rgb666.c、module_drivers/drivers/video/fbdev/ingenic/fb_stage/displays/panel-tl040wvs03ct.cMIPI DBI typeB（MCU 80 接口）SLCD 驱动参考：module_drivers/drivers/video/fbdev/ingenic/fb_stage/displays/panel-kd035hvfbd037.cX2000 Camera 驱动参考当前支持 sensor 驱动路径：kernel-4.4.94/module_drivers/drivers/media/i2c/ingenic-ispMIPI 接口 sensor：ov2735a.cDVP 接口 sensor：ov2735b.cX2500 Camera 驱动参考当前 sensor 驱动路径：module_drivers/drivers/media/i2c/ingenic-isp-v2MIPI 接口 sensor：sc230ai.cDVP 接口 sensor：gc2155.cBT1120 输入接口 sensor：ov491.cX2000 平台问题（Q&A）Q: x2000 source lunch 的编译选项应该如何选择？A: 需要按照下面步骤确认对应编译选项：确认芯片型号：X2000 系列（X2000/X2000E/X2000H）还是 X2100。确认板级：X2000 系列（X2000/X2000E/X2000H）应选择 halley5*，X2100 选择 kale*，详见表 1。确认硬件版本：检查开发板底板丝印信息，硬件底板丝印信息与 lunch 的版本号保持一致，详见表 2。确认存储介质：检查开发板焊接的存储介质是 nor、nand 还是 emmc，并与 lunch 的存储介质类型保持一致。确认内核版本：如果编译 kernel 4.4.94，选择带 4.4.94 的 lunch 编译选项；如果编译 kernel 5.10，选择带 5.10 的 lunch 编译选项。是否需要 OTA：需要则选择带 ota 的 lunch 选项；不需要则选择不带 ota 的选项。板级版本号存储介质X2000/X2000E/X2000Hhalley5v10/v20/v30 + nor/nand/emmcX2100kalev10 + nor/nand/emmc表 1：软件 lunch 编译选项分解说明芯片底板丝印版本号X2000/X2000E/X2000HRD_X2000_HALLEY5_BASEBOARD_V1.Xv10X2000/X2000E/X2000HRD_X2000_HALLEY5_BASEBOARD_V2.Xv20X2000/X2000E/X2000HRD_X2000_HALLEY5_BASEBOARD_V3.Xv30X2100RD_X2100_KALE_BASEBOARD_V1_Xv10表 2：硬件底板丝印对应软件版本号说明下面以默认开发板 X2000 Halley5 为例：芯片：X2000。板级：halley5。底板丝印：RD_X2000_HALLEY5_BASEBOARD_V3.0。默认存储介质：nand。内核版本：kernel 4.4.94。不带 OTA 功能。lunch 编译选项应选择：halley5.v30_nand_4.4.94-engX1600 平台问题（Q&A）Q: x1600 source lunch 的编译选项应该如何选择？A: 需要按照下面步骤确认对应编译选项：确认芯片型号：X1600 系列（X1600/X1600E/X1600EN/X1600HN/X1600MN）还是 X1660 系列（X1660/X1660L）。确认板级：X1600 系列按开发板选择 halley6* 或 panda*；X1660 系列选择 x1660evb*，详见表 1。确认硬件版本：检查开发板底板丝印信息，硬件底板丝印信息与 lunch 的版本号保持一致，详见表 2。确认存储介质：检查开发板焊接的存储介质是 nor、nand 还是 emmc，并与 lunch 的存储介质类型保持一致。确认内核版本：如果编译 kernel 4.4.94，选择带 4.4.94 的 lunch 编译选项；如果编译 kernel 5.10，选择带 5.10 的 lunch 编译选项。是否需要 OTA：需要则选择带 ota 的 lunch 选项；不需要则选择不带 ota 的选项。芯片板级版本号存储介质X1600/X1600E/X1600EN/X1600HN/X1600MNhalley6v10nor/nand/emmcX1600/X1600E/X1600EN/X1600HN/X1600MNpandav10nor/nand/emmcX1660/X1660Lx1660evbv10nand表 1：软件 lunch 编译选项分解说明芯片板级底板丝印版本号X1600/X1600E/X1600EN/X1600HN/X1600MNhalley6HALLEY6_BASEBOARD_V1.0v10X1600/X1600E/X1600EN/X1600HN/X1600MNhalley6HALLEY6_BASEBOARD_V2.0v10X1600/X1600E/X1600EN/X1600HN/X1600MNhalley6HALLEY6_BASEBOARD_V2.0.1v10X1660/X1660Lx1660evbX1660_EVB_V2P0v10表 2：硬件底板丝印对应软件版本号说明下面以默认开发板 X1600 Halley6 为例：芯片：X1600E。板级：halley6。底板丝印：HALLEY6_BASEBOARD_V1.0。默认存储介质：nand。内核版本：kernel 4.4.94。不带 OTA 功能。lunch 编译选项应选择：halley6.v10_nand_4.4.94-engX2500 平台问题（Q&A）Q: X2500 source lunch 的编译选项应该如何选择？A: 需要按照下面步骤确认对应编译选项：确认芯片型号：X2500 系列（X2500/X2500a）。确认板级：X2500 系列选择 hippo*，详见表 1。确认硬件版本：检查开发板底板丝印信息，硬件底板丝印信息与 lunch 的版本号保持一致，详见表 2。确认存储介质：检查开发板焊接的存储介质是 nor、nand 还是 emmc，并与 lunch 的存储介质类型保持一致。确认内核版本：如果编译 kernel 4.4.94，选择带 4.4.94 的 lunch 编译选项；如果编译 kernel 5.10，选择带 5.10 的 lunch 编译选项。是否需要 OTA：需要则选择带 ota 的 lunch 选项；不需要则选择不带 ota 的选项。芯片板级版本号存储介质X2500/X2500ahippov10/v12nor/nand/emmc表 1：软件 lunch 编译选项分解说明芯片底板丝印版本号X2500/X2500aRD_X2500_HIPPO_BASEBOARD_(V1.0/V1.0.1/V1.1/V1.1.1)v10X2500/X2500aRD_X2500_HIPPO_BASEBOARD_V1.2v12表 2：硬件底板丝印对应软件版本号说明下面以默认开发板 X2500 Hippo 为例：芯片：X2500。板级：hippo。底板丝印：RD_X2500_HIPPO_BASEBOARD_V1.2。默认存储介质：emmc。内核版本：kernel 4.4.94。不带 OTA 功能。lunch 编译选项应选择：hippo.v12_msc_4.4.94-eng
X系列通用板级创建指导说明
通用板级编译配置与构建指导示例参考参考板级代码:test.tar.bz2 (2.9MB)1. 适用范围本文用于指导在 Manhattan Linux SDK 中创建新的板级产品配置，并完成 U-Boot、Linux 内核、设备树、Buildroot 文件系统和板级应用模块的接入。本文只描述通用方法，不绑定具体客户或项目。为了便于阅读，全文使用一个虚拟示例进行说明：板级名称为 test，芯片平台为 x2600，内核版本为 5.10，存储介质为 nand。因此，示例中的板级目录是 device/test/，实际项目只需要将 test 替换为自己的板级名称即可。文中仍使用 、、 等占位符表示通用写法时，对应的示例分别是：test、x2600、5.10。不同 SDK 版本的目录名和变量可能存在差异。开始修改前，应优先参考当前 SDK 中已有的同系列板级目录、build/core 构建规则和内核源码中的参考 defconfig。2. 板级目录与构建链路通用结构如下：device/├── vendorsetup.sh 注册 lunch 选项├── device.mk 平台、存储介质和文件系统配置├── Build.mk 引入 U-Boot、内核及其他模块├── uboot.mk U-Boot 编译参数├── kernel.mk 内核编译参数├──├── kernel_cfg/ 板级内核 defconfig├── kernel_overlay/ 内核源码覆盖文件├── kernel-├── uboot_overlay/ U-Boot 源码覆盖文件├── rootfs-overlay/ 根文件系统覆盖文件└── ota-overlay/ 可选，OTA、分区和升级脚本以本文示例展开后，目录可以写成：device/test/├── vendorsetup.sh├── device.mk├── Build.mk├── uboot.mk├── kernel.mk├── test_base.mk├── kernel_cfg/5.10/├── kernel_overlay/├── kernel-5.10/├── uboot_overlay/├── rootfs-overlay/└── ota-overlay/图 1：test 板级目录结构示例整体流程为：vendorsetup.sh 注册产品 → lunch 解析产品参数 → device.mk 设置产品属性 → kernel.mk/uboot.mk 注册编译模块 → overlay 覆盖源码 → 外置 Kconfig/Makefile 接入板级代码 → 生成镜像。推荐从以下模板或同系列板级目录复制：build/core/templates/device/template/复制后必须逐项核对变量和目录结构，不要直接沿用旧 SDK 的配置。复制已有板级目录时，建议先完整复制，再只替换板级名称相关的文件名和文本引用。以本文的 test 示例为例：cp -a device/find device/test -depth -name '*rg -n -i '检查无误后，再根据实际芯片和内核版本确认 device.mk、kernel.mk、uboot.mk、defconfig、boards.cfg 和设备树文件。图 2：复制板级目录并检查代码改动3. 注册 lunch 产品vendorsetup.sh 由 build/envsetup.sh 执行，使用 add_lunch_combo 注册产品。推荐产品名结构如下：本文示例使用 test、x2600、nand 和 5.10：#!/bin/shadd_lunch_combo test.x2600e_nand_5.10-engadd_lunch_combo test.x2600e_nand_5.10_ota-eng实际项目可将 test 替换为板级目录名，x2600 替换为对应平台标识；存储介质和内核版本必须与实际构建配置一致。创建后执行：source build/envsetup.shlunch确认以下变量被正确解析：TARGET_DEVICE、TARGET_STORAGE_MEDIUM、TARGET_EXT_SUPPORT、TARGET_EXT2_SUPPORT 和 TARGET_PRODUCT。4. 配置板级入口文件4.1 device.mkdevice.mk 负责平台信息、Buildroot 配置、根文件系统 overlay 和存储介质参数。PRODUCT := productTARGET_PRODUCT_BOARD := $(TARGET_DEVICE)TARGET_BOARD_PLATFORM := "x2600"TARGET_BOARD_ARCH := "mips"TARGET_ARCH_VARIANT := mips32r2_fp64LOCAL_PATH := $(shell dirname $(lastword $(MAKEFILE_LIST)))DEVICE_PATH := $(TOP_DIR)/$(LOCAL_PATH)MAKE_JLEVEL := 4注意：TARGET_ARCH_VARIANT 必须与芯片所属架构匹配。xburst 芯片使用 mips32r2，例如 x1600。xburst2 芯片使用 mips32r2_fp64，例如 x2000、x2600。device.mk 中的配置示例：# xburst2 芯片，例如 x2000、x2600TARGET_ARCH_VARIANT := mips32r2_fp64# xburst 芯片，例如 x1600# TARGET_ARCH_VARIANT := mips32r2两种配置不能同时启用。新增板级目录时，应先确认芯片平台，再选择对应的 TARGET_ARCH_VARIANT，否则可能出现工具链、编译选项或最终程序运行不匹配的问题。存储介质相关配置应放在条件分支中：ifeq ($(strip $(TARGET_STORAGE_MEDIUM)),nand)ROOTFS_OVERLAY_DIR := $(DEVICE_PATH)/rootfs-overlayBUILDROOT_CONFIG := x2600e_test_linux_defconfigBUILDROOT_CONFIG_PATH := $(DEVICE_PATH)FILE_SYSTEM_TYPE := ubifsendifOTA 配置、分区配置和升级脚本也应只在对应产品条件下加入，避免不同存储介质相互污染。4.2 Build.mk 和 Build.mk 负责引入板级编译规则：include $(DEVICE_PATH)/uboot.mkinclude $(DEVICE_PATH)/kernel.mkifeq ($(strip $(TARGET_EXT2_SUPPORT)),ota)include $(DEVICE_PATH)/kernel-recovery.mkendif 通过 PRODUCT_MODULES 选择产品模块。本文示例对应的文件名为 test_base.mk：PRODUCT_MODULES := uboot \ kernelPRODUCT_MODULES +=例如，若应用模块的 LOCAL_MODULE := test-app，则可以写成：PRODUCT_MODULES += test-app追加的名称应取自模块 Build.mk 中的 LOCAL_MODULE，而不是目录名。使用以下命令确认模块是否被选中：make show-modules4.3 uboot.mkUBOOT_BUILD_CONFIG := x2600e_test_uImage_sfc_nandUBOOT_TARGET_FILE := u-boot-with-spl.binUBOOT_PATH := $(TOP_DIR)/u-bootUBOOT_BOARD_PATH := $(LOCAL_PATH)/uboot_overlayLOCAL_MODULE := ubootinclude $(BUILD_UBOOT)需要确认：UBOOT_BUILD_CONFIG 在 boards.cfg 中存在对应条目。uboot_overlay/ 与 U-Boot 源码保持相同目录结构。例如 include/configs/test.h、board/ingenic/test/ 下的板级 C 文件和 Makefile 路径一致。启动介质、串口、bootargs、分区和镜像加载地址符合硬件方案。单独验证：make uboot4.4 kernel.mkKERNEL_VER := 5.10KERNEL_PATH := $(TOP_DIR)/kernel/kernel-5.10KERNEL_BOARD_PATH := $(LOCAL_PATH)/kernel-5.10KERNEL_CONFIG_PATH := $(DEVICE_PATH)/kernel_cfg/5.10KERNEL_BUILD_CONFIG := x2600e_test_v10_linux_defconfigKERNEL_BOARD_OVERLAY_PATH := $(LOCAL_PATH)/kernel_overlayKERNEL_TARGET_IMAGE := uImageKERNEL_IMAGE_PATH := arch/mips/boot/LOCAL_MODULE := kernelinclude $(BUILD_KERNEL)OTA 或压缩内核场景可能改为：KERNEL_TARGET_IMAGE := xImageKERNEL_IMAGE_PATH := arch/mips/boot/compressed/当前 build/core/build_kernel.mk 的关键行为是：复制 KERNEL_BOARD_OVERLAY_PATH、复制 KERNEL_CONFIG_PATH 中的 defconfig、通过 OUTSIDE_BUILD 传入 KERNEL_BOARD_PATH，最后构建内核镜像、模块和设备树。5. 设备树配置方式设备树不是只放置一个 .dts 文件即可。推荐使用 defconfig + 外置 Kconfig + 外置 Makefile + DTS/DTSI 的完整链路。5.1 推荐目录结构device/├── Kconfig├── Makefile└── board- ├── Kconfig ├── Makefile └── device-dts/ ├── Makefile ├── └──本文示例对应为：device/test/kernel-5.10/├── Kconfig├── Makefile└── board-x2600/ ├── Kconfig ├── Makefile └── device-dts/ ├── Makefile ├── x2600e_test.dts └── test_display.dtsi5.2 外置 Kconfig顶层 Kconfig 引入板级 Kconfig：menu "external driver"source "$(OUTSIDE_BUILD)/board-x2600/Kconfig"endmenu板级 Kconfig 提供板级选择：choice prompt "External Board Name" depends on DT_XBURST2_EXTERNAL_BOARD default DT_X2600E_TESTconfig DT_X2600E_TEST bool "test x2600 board"endchoiceDT_XBURST2_EXTERNAL_BOARD 必须由 SoC Kconfig 提供并在 defconfig 中打开；DT_ 必须与设备树 Makefile 中的配置符号完全一致。图 3：外置 Kconfig、Makefile、defconfig 与 DTB 的配置链路5.3 各级 Makefile# kernel-obj-y += board-x2600/# board-obj-y += device-dts/# device-dts/Makefiledtb-$(CONFIG_DT_X2600E_TEST) += x2600e_test.dtbobj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))always := $(dtb-y)clean-files := *.dtb *.dtb.S只增加 .dts 而不增加 Makefile，或只增加 Kconfig 选项而没有 dtb-$(CONFIG_...) 规则，都可能导致能配置但不生成 DTB。5.4 DTS 编写和核对重点/dts-v1/;#include#include/ { compatible = "vendor,test", "vendor,x2600";};&uart0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 =};修改 DTS 时依次确认：公共 SoC DTSI、GPIO、时钟、引脚复用和外设节点来自当前内核版本。根节点 compatible 与实际 SoC、板级产品一致。未使用外设为 disabled，使用外设为 okay。UART、I2C、SPI、MMC、LCD 等设备的 pinctrl 与原理图一致。GPIO、regulator、reset-gpios 的有效电平正确。MMC/SFC 的总线宽度、频率、电压和非易失存储属性正确。reserved-memory 不与 DDR、协处理器和 DMA 缓冲区重叠。DTS 中使用的 CONFIG_... 选项确实存在于本次 .config。图 4：x2600e_test.dts 设备树文件修改示例5.5 defconfig 到 DTB 的选择链路SoC Kconfig → CONFIG_DT_XBURST2_EXTERNAL_BOARD=y → 外置 board-x2600/Kconfig → CONFIG_DT_X2600E_TEST=y → device-dts/Makefile 中的 dtb-$(CONFIG_DT_X2600E_TEST) → 生成 x2600e_test.dtb建议在板级 defconfig 中检查：CONFIG_OF=yCONFIG_DT_XBURST2_EXTERNAL_BOARD=yCONFIG_DT_X2600E_TEST=yCONFIG_OUTSIDE_BUILD=".../device/test/kernel-5.10"CONFIG_OUTSIDE_BUILD 的最终值由构建系统传入，不建议写死绝对路径。以构建生成的 .config 为准：grep -E 'CONFIG_OF=|CONFIG_DT_|CONFIG_OUTSIDE_BUILD' \ out/product/6. 设备树和内核验证make kernelfind out -name 'x2600e_test.dtb' -o -name 'x2600e_test.dtb.S'需要确认：编译日志没有 DTS 语法错误、未定义标签或找不到 include 文件。生成的 DTB 名称与 device-dts/Makefile 一致。目标 DTB 没有被误编译成其他板级 DTB。启动后可通过 /sys/firmware/devicetree/base/compatible 检查兼容性字符串。关键外设的设备节点、内核日志和运行状态符合预期。7. 文件系统、OTA 与整体构建rootfs-overlay 的目录结构应与目标根文件系统一致，适合放置启动脚本、默认配置、校准数据和随系统发布的工具。OTA 场景重点确认：分区配置与 U-Boot 分区表、内核 MTD 分区一致。normal/recovery 镜像名称和启动参数一致。升级脚本使用的设备节点与实际存储介质一致。OTA overlay 只在 OTA lunch 选项下加入。推荐按从局部到整体的顺序验证：source build/envsetup.shlunchmake show-modulesmake ubootmake kernelmake buildrootmake -j$(nproc)如果当前 SDK 没有 make buildroot 目标，以 make help 或当前板级文档为准。8. 建立完成确认清单☐ vendorsetup.sh 的 lunch 选项可以显示并正确解析。☐ device.mk 的平台、架构、Buildroot 配置和文件系统类型匹配。☐ Build.mk 引入了实际需要的构建规则。☐ UBOOT_BUILD_CONFIG 在 boards.cfg 中有对应条目。☐ U-Boot overlay 与源码树路径一致，make uboot 通过。☐ KERNEL_PATH、KERNEL_CONFIG_PATH 和 KERNEL_BUILD_CONFIG 相互匹配。☐ KERNEL_BOARD_OVERLAY_PATH 和 KERNEL_BOARD_PATH 指向正确位置。☐ defconfig 打开设备树和外置板级配置选项。☐ 外置 Kconfig、各级 Makefile 和 DTS 文件逐级连通。☐ CONFIG_DT_ 与 dtb-$(CONFIG_DT_ 名称一致。☐ DTS 的 GPIO、pinctrl、电源、复位、时钟、总线参数和保留内存已按原理图确认。☐ 构建输出中实际生成目标 DTB，且镜像流程使用该 DTB。☐ OTA 配置、分区表和启动参数一致。☐ make show-modules 和整体 make 的结果符合产品预期。9. 常见问题定位现象优先检查项lunch 看不到新产品vendorsetup.sh 是否被扫描、脚本是否可执行、产品名格式是否正确找不到 defconfigKERNEL_CONFIG_PATH、KERNEL_BUILD_CONFIG 和内核版本目录看不到外置板级 KconfigKERNEL_BOARD_PATH、OUTSIDE_BUILD 和顶层 Kconfig 的 source 路径能配置但没有生成 DTBCONFIG_DT_、device-dts/Makefile、always 和 dtb-$(CONFIG_...)DTS 找不到 includeoverlay 是否复制到内核源码、DTSI 相对路径和 include 搜索路径设备树通过但外设不工作status、pinctrl、GPIO 有效电平、电源、时钟、复位和总线参数U-Boot 能编译但不能启动启动介质、分区、bootargs、串口和内核/DTB 加载地址整体构建未编译板级应用应用 LOCAL_MODULE 是否加入 的 PRODUCT_MODULES10. 维护建议升级 SDK、内核或 U-Boot 后，重新核对模板变量和公共 DTSI。硬件变更时，优先同步 DTS、U-Boot 配置头文件、分区配置和 rootfs 启动脚本，再执行单模块验证。设备树修改应同时保存 defconfig、Kconfig、Makefile 和 DTS，避免只提交部分文件。将实际构建命令、镜像输出位置和烧录配置记录在项目 README 中；本文只作为通用方法。
X1600产品硬件设计问题总结
X1600产品硬件设计问题总结1. PLL_AVDD供电应该是1.8V，电容建议就近放置，如果电容布局较远，建议增加一个10uF电容，10uF+0.1uF，此路走线建议12mil以上。2. PLL_VDD走线建议12mil以上。3. DDR_VDD1_1和DDR_VDD1_2走线建议加粗15mil以上。4. DDR_PLLVCCA走线建议12mil以上，电容尽量就近放置，如果放置较远，建议10uF+0.1uF5. RAM_VREF走线建议10mil以上6. 上电时序：1.1V-1.8V-3.3V-1.2V，1.1V和1.2V电流较大，大概500mA左右，1.8V和3.3V电流次之，大概300mA左右。这四路电源从EA3036和BL1117出来后不要过磁珠，直接进CPU。7. 32.768K晶体选择建议用CL为6pF的，外面匹配的电容建议10pF左右，启振时间大概在400ms左右。并联的电阻是10M的。8. 如果需要备电给RTC供电，则RTC_VDD和RTC_AVDD都需要独立供电，其中RTC_VDD接1.1V，RTC_AVDD接3.3V或者1.8V，为节省成本，RTC_VDD可以用电阻分压，由于芯片内部也有阻值，外接电阻分压需要调整，我用47K和100K能分出1V左右。9.电源缓起电路：
X系列通用Uboot下读写ubi 方法
U-Boot 下读写 UBI 方法1. 依赖的环境变量U-Boot 的 mtdparts 命令依赖两个环境变量：1. mtdids：U-Boot 设备名 <-> Linux MTD 名的映射2. mtdparts：分区表定义注意：• mtdids=nand0:nand 不是这里使用的格式• mtdparts=mtdparts=nand:... 可用2. 操作步骤2.1 修正 mtdidssetenv mtdids nand0=nandprintenv mtdids# 期望看到：mtdids=nand0=nand2.2 设置 mtdparts（你的板子分区）setenv mtdparts 'mtdparts=nand:1M(boot),8M(kernel),40M(rootfs),-(data)'printenv mtdparts# 期望看到：mtdparts=mtdparts=nand:1M(boot),8M(kernel),40M(rootfs),-(data)2.3 解析并展示分区表mtdparts预期：看到 nand0 下 4 个分区：boot / kernel / rootfs / data。2.4 清空 data 分区并初始化为 UBI危险：会擦除 data 分区nand erase.part dataubi part dataubi info2.5 创建卷并做读写验证ubi create datavol 0x1400000 dubi info lubi write 0x82000000 datavol 0x100000ubi read 0x83000000 datavol 0x100000md.b 0x83000000 0x402.6 持久化（确认没问题后再保存）saveenv3. 快速自测（固定字节）# 往 0x82000000 填充 0x5A，共 0x1000 字节mw.b 0x82000000 0x5A 0x1000# 写入卷ubi write 0x82000000 datavol 0x1000# 读回到 0x83000000ubi read 0x83000000 datavol 0x1000# 检查前 64 字节应基本都是 5Amd.b 0x83000000 0x404. 实测日志 x2000_halley5# printenv mtdids mtdids=nand0:nand x2000_halley5# printenv mtdparts mtdparts=mtdparts=nand:1M(boot),8M(kernel),40M(rootfs),-(data) x2000_halley5# setenv mtdids nand0=nand x2000_halley5# setenv mtdparts 'mtdparts=nand:1M(boot),8M(kernel),40M(rootfs),-(data)' x2000_halley5# mtdparts device nand0 <nand>, # parts = 4 #: name size offset mask_flags 0: boot 0x00100000 0x00000000 0 1: kernel 0x00800000 0x00100000 0 2: rootfs 0x02800000 0x00900000 0 3: data 0x04f00000 0x03100000 0 active partition: nand0,0 - (boot) 0x00100000 @ 0x00000000 defaults: mtdids : nand0:nand mtdparts: mtdparts=nand:1M(boot),8M(kernel),40M(rootfs),-(data) x2000_halley5# nand erase.part data NAND erase.part: device 0 offset 0x3100000, size 0x4f00000 Erasing at 0x7fe0000 -- 100% complete. OK x2000_halley5# x2000_halley5# ubi part data UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 79 MiB UBI: number of good PEBs: 632 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 616 UBI: total number of reserved PEBs: 16 UBI: number of PEBs reserved for bad PEB handling: 12 UBI: max/mean erase counter: 1/0 x2000_halley5# ubi info UBI: MTD device name: "mtd=3" UBI: MTD device size: 79 MiB UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: number of good PEBs: 632 UBI: number of bad PEBs: 0 UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 616 UBI: total number of reserved PEBs: 16 UBI: number of PEBs reserved for bad PEB handling: 12 UBI: max/mean erase counter: 1/0 x2000_halley5# x2000_halley5# ubi create datavol 0x1400000 d Creating dynamic volume datavol of size 20971520 x2000_halley5# ubi info l UBI: volume information dump: UBI: vol_id 0 UBI: reserved_pebs 166 UBI: alignment 1 UBI: data_pad 0 UBI: vol_type 3 UBI: name_len 7 UBI: usable_leb_size 126976 UBI: used_ebs 166 UBI: used_bytes 21078016 UBI: last_eb_bytes 126976 UBI: corrupted 0 UBI: upd_marker 0 UBI: name datavol UBI: volume information dump: UBI: vol_id 2147479551 UBI: reserved_pebs 2 UBI: alignment 1 UBI: data_pad 0 UBI: vol_type 3 UBI: name_len 13 UBI: usable_leb_size 126976 UBI: used_ebs 2 UBI: used_bytes 253952 UBI: last_eb_bytes 2 UBI: corrupted 0 UBI: upd_marker 0 UBI: name layout volume x2000_halley5# ubi write 0x82000000 datavol 0x100000 1048576 bytes written to volume datavol x2000_halley5# ubi read 0x83000000 datavol 0x100000 Read 1048576 bytes from volume datavol to 83000000 x2000_halley5# md.b 0x83000000 0x40 83000000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 04 UBI#............ 83000010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00 ................ 83000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 83000030: 00 00 00 00 00 00 00 00 00 00 00 00 3f 05 d0 a6 ............?...x2000_halley5# ubi write 0x82000000 datavol 0x1000001048576 bytes written to volume datavolx2000_halley5# ubi read 0x83000000 datavol 0x100000Read 1048576 bytes from volume datavol to 83000000x2000_halley5# md.b 0x83000000 0x4083000000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 04 UBI#............83000010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00 ................83000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................83000030: 00 00 00 00 00 00 00 00 00 00 00 00 3f 05 d0 a6 ............?...x2000_halley5#x2000_halley5# mw.b 0x82000000 0x5A 0x1000x2000_halley5# ubi write 0x82000000 datavol 0x10004096 bytes written to volume datavolx2000_halley5# ubi read 0x83000000 datavol 0x1000Read 4096 bytes from volume datavol to 83000000x2000_halley5# md.b 0x83000000 0x4083000000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ83000010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ83000020: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ83000030: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZx2000_halley5#