在烧录成功的情况下,回到本帖子一楼,日志检擦bl2失败,如何解决问题? 我用的是官方的代码,此编译的boot已经可以成功在官方的开发板上运行,但是官方开发板上的nand flash是1Gb的
问题已经定位:一楼冷启动日志里 BootROM 显示 is_dummy = true、PAGE_SIZE_4K,但成功烧录日志中这颗 NAND 实际是 2 KiB 页。这说明 BootROM 只读到了器件 ID,并没有正确匹配 GD5F2GM7REYIG 的参数,所以 XBurn 能通过临时 U-Boot 写入,冷启动却读不出 BL2。
这个问题继续重烧解决不了,需要板级/启动链研发确认 BootROM 是否支持该 ID,以及 2 KiB 页参数的配置方式;如果 BootROM 无法适配,就要换用已验证支持的 NAND。官方开发板能启动,只能说明原来的 1Gb 配置正常。
好的我知道问题了,如何在RDK开发环境了找到对应的部分,进行修改适配。
这个换的就是已验证支持的nand 我可以在boot源码下的gigadevice.c里找到对应的支持。但是效果就和1楼一样
你在 gigadevice.c 里看到支持项,只能说明临时 U-Boot/驱动能识别这颗 NAND;冷启动时的 BL1/BootROM 在它之前运行,不会走这里的驱动。现在冷启动仍识别成 PAGE_SIZE_4K、is_dummy = true,而临时 U-Boot 识别为 2 KiB 页,说明问题还在启动 ROM/FSP 的器件参数匹配。
这不是改 gigadevice.c 就能解决的,需要启动链研发核对 BootROM 对该完整 ID 的支持、FSP/BL2 配置和 2 Gb 布局;如果 BootROM 不能适配,只能换已验证可冷启动的型号。这个已属于板级二次开发范围。
参考:https://developer.d-robotics.cc/rdk_x_doc/Quick_start/system-burn/upgrade-miniboot
如何找启动链研发核对? 这个是平台烧录到芯片rom区的程序? 开发者无法进行修改? 只能够有芯片厂商修改吗?
BootROM(BL1)在芯片内部 IROM 中固化,开发者不能通过 RDK 编译或刷机改写,厂商也不能像更新 NAND 固件那样直接重刷这段 ROM。不过,目前日志只能说明 BL2 加载失败及页参数存在疑点,我前面把它说成已经确定的 BootROM 不支持,结论过早;是否能通过配套启动配置解决,还需研发确认。
可联系 developer@d-robotics.cc,附上本帖链接、NAND 型号和 boot 源码版本,说明需要 X5 启动链支持;如有需要,我们也可以协助对接。
请你帮我协助对接
收到,我们会向研发同事对接该问题支持,如有进展,会同步到此帖子下
官方不支持这个修改 硬件更换啥的一般都需要自定义底板,走dgp
好的 感谢你的回复
你这段日志只到 Step 5: fastboot_burn,没看到最终报错。如果卡住/失败,优先怀疑板子没进 fastboot,或 PC 没识别到 fastboot USB 设备。
先查这几步:
-
看串口日志有没有进入 U-Boot/fastboot,比如
fastboot 0、boot action: FASTBOOT USB2.0。
如果没进去,重新上电再烧;xmodem_fastboot建议把波特率改成921600,并按手册把拨码 D4 置 1。 -
Windows 设备管理器里确认是否出现
Android Bootloader Interface/ fastboot 设备。没有就重装 USB Driver,换 USB2.0 口和线,别走 Hub。可先验证:
fastboot devices
- 确认
COM3没被其他串口工具占用,且确实是目标串口:
xburn -s serial
如果还不行,把 Step 5 之后的完整报错,以及串口里 U-Boot 那段日志贴出来。
从这段日志看,配置本身没明显问题;如果用 xmodem_fastboot 卡住/失败,最可疑的是 串口波特率还是 115200,Xmodem 阶段容易慢到像挂死或超时。
先按这个查:
- 把波特率改成
921600再试:
--baudrate 921600
同时确认板子支持 921600(X5 EVB 一般对应拨码开关 D4 置 1)。
-
点“开始升级”后,再给板子上电/复位。串口里应能看到进入 xmodem 下载、再进 fastboot 的日志;如果一直停在
Please power on or reboot the Board!,多半是串口通信/上电时序问题。 -
确认镜像目录里确实有这些文件:
uart_usb/bl2_uart_ddr.bin
uart_usb/bl3x_all.bin
以及对应的 nand/secure 镜像和 json。
如果改 921600 后还失败,把失败后的最后一段 xburn 日志,以及串口输出贴出来;重点看是卡在 xmodem_boot 还是 fastboot_burn。