您尚未登录。

页次： 1

分享链接 / 只看楼主

楼主 # 昨天 19:22:27

xzyang
会员
注册时间： 2019-10-27
已发帖子： 29
积分： 19

D133EBS更换D133ECS后烧录失败

固件MMC方式，D133EBS时一切正常，更换D133ECS后启动时串口打印
Pre-Boot Program ... (24-02-04 17:43 3c323c3 dirty)
SD
can't get the psram table, return the default info.

用最新AiBurn1.53版本烧写，串口打印

Pr▒-Boot Program ... (24-02-04 17:43 3c323c3 dirty)
USB/UART
can't get the psram table, return the default info.

AiBurn1.53 烧写时的log
[debug] Start burn online ...
[debug] Scan the current 4 partitions in list ...
[debug] Part name: spl , Selected: false
[debug] Part name: os , Selected: true
[debug] Part name: rodata , Selected: false
[debug] Part name: data , Selected: false
[debug] Progress range: 0 ~ 170688512

[debug] Burn Image file "D:/D133ebs/baremetal/output/mmc_baremetal_app/images/d13x-mmc_v1.0.1.img" ...

[debug] Meta 0 image.updater.spl , size 158992 ...
[debug] Blocksize 4 , chunk 1048576 * 0 , rest 158992
[debug] Offset: 5632 Size: 158992
[debug] Dev "2:6-4-1" Send the rest data 158992
[info ] aicupg_trans_recv_pkt()322: no CSW. (rc = 0)
[info ] aicupg_cmd_send_fwc_data_final()726: no resp
[debug] Don't check the result of image.updater.spl
[debug] Wait to reconnect dev "2:6-4-1"
[debug] QTime("19:18:26.073") Wait for Dev "2:6-4-1" ready
[error] QTime("19:18:38.760") Dev "2:6-4-1" lost!
[error] Dev "2:6-4-1" is completely lost!
更换16MB PSRAM版本后需要更改哪里？

离线

#1 昨天 19:59:10

点点滴滴
会员
注册时间： 昨天
已发帖子： 2
积分： 2

Re: D133EBS更换D133ECS后烧录失败

看这个现象，我觉得重点不在 AiBurn 版本，而是在最前面的 PBP/SPL 没拿到正确的 PSRAM 参数。

日志里这句其实已经把方向说出来了：

SD can't get the psram table, return the default info.
USB/UART can't get the psram table, return the default info.

D133EBS 能跑，换 D133ECS 后烧录时设备传完 image.updater.spl 就 lost，大概率是 updater spl 跑起来后初始化 PSRAM 失败或者用了错误的默认 PSRAM 参数，后面 USB 升级协议就断了。所以不是单纯 os 分区的问题，应该先查启动头/board 配置里给 PBP 用的 psram table。

我会按这个顺序排：

  1. 先确认 D133EBS 和 D133ECS 的 PSRAM 型号、容量、IO 模式、频率是不是一致。你说换成 16MB PSRAM 版本，那原来 EBS 很可能不是同一套参数。PSRAM 不是只改个容量就完事，timing/drive/latency 有时候也要跟着变。

  2. 找工程里和 psram table、dram_para、boot0/bootloader header、board.dts、sys_config 类似的配置。这个表通常不是应用层用的，而是给 PBP/SPL 很早期初始化内存用的；如果镜像里没带，PBP 就会打印你看到的 “can't get the psram table, return the default info”。

  3. 注意 AiBurn 烧录用的是 image.updater.spl。也就是说你要改的不只是正常启动用的 spl，有些 SDK 会单独生成 updater spl / usb burn spl。正常启动镜像改了，但 updater 还是旧板子的 PSRAM 参数，也会出现“启动能看到一点打印，但烧录马上掉线”。

  4. 先不要烧完整 os，建议只选 spl 或最小镜像测试。只要 updater spl 能稳定起来，USB 设备不会 lost，后面 os/rodata/data 再说。现在 log 是发完 spl 后等设备重连失败，说明第一阶段就没站稳。

  5. 串口乱码那个 Pr▒-Boot Program 也可以顺手确认一下波特率/时钟，不过这个不是主因。主因还是后面明确报了 psram table fallback。

所以回答“16MB PSRAM 版本需要改哪里”：优先改板级 PSRAM 参数表，并确认这个参数表同时进了正常启动 spl 和 AiBurn 用的 updater spl。改完后看串口里还会不会出现 can't get the psram table，如果这句消失，再看是否还能在传完 spl 后掉 USB。

离线

楼主 #2 昨天 20:22:03

xzyang
会员
注册时间： 2019-10-27
已发帖子： 29
积分： 19

Re: D133EBS更换D133ECS后烧录失败

已经更新了pbp_cfg.json，重新打包固件，并直接写入到卡内，还是一样错误
{
"psram": {

"cfg0": { //OPI APS3208K 8M PSRAM
"common": {
"clock": "198000000",
"cs0_pins": "0x0",
"cs1_pins": "0x0",
"xspi_ctl": "0x116d",
"xspi_tcr": "0x280011",
"xspi_cfg": "0x03020001",
"xspi_ldo": "0x17", //1.92V
"psram_cfg0": "0x03030303",
"psram_cfg1": "0x00400001",
"xspi_cs0_iocfg1": "0x02020202",
"xspi_cs0_iocfg2": "0x02020202",
"xspi_cs0_iocfg3": "0x36060503",
"xspi_cs0_iocfg4": "0x26",
"xspi_cs1_iocfg1": "0x02020202",
"xspi_cs1_iocfg2": "0x02020202",
"xspi_cs1_iocfg3": "0x36060503",
"xspi_cs1_iocfg4": "0x26",
},
"reset": {
"proto": "0xff000001",
"buf": "0x00ffffff",
},
"getid": {
"proto": "0x40030204",
"id": "0x80c980c9",
"buf": "0xffffffff",
},
"init": {
"proto0": "0xc0000002", //cmd: byte[0]=0xc0; dummy: byte[1]=0x00; addr: byte[2]=0x00; len: byte[3]=0x02;
"buf0": "0x19000000",
"proto1": "0xc0000402",
"buf1": "0x80000000",
"proto2": "0xffffffff",
"buf2": "0xffffffff",
"proto3": "0xffffffff",
"buf3": "0xffffffff",
},
"xip_cfg": {
"wr_proto": "0x80020002",
"wr_buf": "0xffffffff",
"rd_proto": "0x00060003",
"rd_buf": "0xffffffff",
},
"backup": {
"buf0": "0xAA55AA55", // training_value1
"buf1": "0x55AA55AA", // training_value2
"buf2": "0x02080100", //byte0:read_hold (0x02); byte1:write_hold (0x08); byte3:axi_read_first(0x01); byte4: bit mode
"buf3": "0xFFFFFF04",
"buf4": "0xFFFFFF05",
"buf5": "0xFFFFFF06",
"buf6": "0xFFFFFF07",
"buf7": "0xFFFFFF08",
"buf8": "0xFFFFFF09",
"buf9": "0xFFFFFF00",
},
},

"cfg1": { // XCCELA AP12816 16M PSRAM
"common": {
"clock": "198000000",
"cs0_pins": "0x0",
"cs1_pins": "0x0",
"xspi_ctl": "0x116d",
"xspi_tcr": "0x280011",
"xspi_cfg": "0x03000001",
"xspi_ldo": "0x17", //1.92V
"psram_cfg0": "0x03030304", //cmd_lines, addr_lines, data_lines, addr_width
"psram_cfg1": "0x02000001",
"xspi_cs0_iocfg1": "0x02020202",
"xspi_cs0_iocfg2": "0x02020202",
"xspi_cs0_iocfg3": "0x36060405",
"xspi_cs0_iocfg4": "0x26",
"xspi_cs1_iocfg1": "0x02020202",
"xspi_cs1_iocfg2": "0x02020202",
"xspi_cs1_iocfg3": "0x36060403",
"xspi_cs1_iocfg4": "0x26",
},
"reset": {
"proto": "0xff000001",
"buf": "0x00ffffff",
},
"getid": {

"proto": "0x40040104",
"id": "0xdd8ddd8d",
"buf": "0xffffffff",
},
"init": {
"proto0": "0xc0000001", //cmd: byte[0]=0xc0; dummy: byte[1]=0x00; addr: byte[2]=0x00; len: byte[3]=0x02;
"buf0": "0x11000000",
"proto1": "0xc0000401",
"buf1": "0x20000000",
"proto2": "0xc0000801",
"buf2": "0x4c000000",
"proto3": "0xffffffff",
"buf3": "0xffffffff",
},
"xip_cfg": {
"wr_proto": "0x80070002", //cmd: byte[0]=0x80; dummy: byte[1]=0x07; addr: byte[2]=0x08; len: byte[3]=0x02;
"wr_buf": "0xffffffff",
"rd_proto": "0x00070003",
"rd_buf": "0xffffffff",
},
"backup": {
"buf0": "0x5555aaaa",
"buf1": "0xaaaa5555",
"buf2": "0x05050101", //byte0:read_hold; byte1:write_hold; byte3:axi_read_first; byte4:bit mode
"buf3": "0xFFFFFF04",
"buf4": "0xFFFFFF05",
"buf5": "0xFFFFFF06",
"buf6": "0xFFFFFF07",
"buf7": "0xFFFFFF08",
"buf8": "0xFFFFFF09",
"buf9": "0xFFFFFF00",
},
},

"cfg2": { // XCCELA UnilC SCKW18X12816 16M PSRAM
"common": {
"clock": "198000000",
"cs0_pins": "0x0",
"cs1_pins": "0x0",
"xspi_ctl": "0x116d",
"xspi_tcr": "0x280011",
"xspi_cfg": "0x03000001",
"xspi_ldo": "0x17", //1.92V
"psram_cfg0": "0x03030304", //cmd_lines, addr_lines, data_lines, addr_width
"psram_cfg1": "0x02000001",
"xspi_cs0_iocfg1": "0x02020202",
"xspi_cs0_iocfg2": "0x02020202",
"xspi_cs0_iocfg3": "0x36060405",
"xspi_cs0_iocfg4": "0x26",
"xspi_cs1_iocfg1": "0x02020202",
"xspi_cs1_iocfg2": "0x02020202",
"xspi_cs1_iocfg3": "0x36060403",
"xspi_cs1_iocfg4": "0x26",
},
"reset": {
"proto": "0xff000001",
"buf": "0x00ffffff",
},
"getid": {

"proto": "0x40040104",
"id": "0xc59ac59a",
"buf": "0xffffffff",
},
"init": {
"proto0": "0xc0000001", //cmd: byte[0]=0xc0; dummy: byte[1]=0x00; addr: byte[2]=0x00; len: byte[3]=0x02;
"buf0": "0x10000000",
"proto1": "0xc0000401",
"buf1": "0x20000000",
"proto2": "0xc0000801",
"buf2": "0x4c000000",
"proto3": "0xffffffff",
"buf3": "0xffffffff",
},
"xip_cfg": {
"wr_proto": "0x80070002", //cmd: byte[0]=0x80; dummy: byte[1]=0x07; addr: byte[2]=0x08; len: byte[3]=0x02;
"wr_buf": "0xffffffff",
"rd_proto": "0x00070003",
"rd_buf": "0xffffffff",
},
"backup": {
"buf0": "0x5555aaaa",
"buf1": "0xaaaa5555",
"buf2": "0x05050101", //byte0:read_hold; byte1:write_hold; byte3:axi_read_first; byte4:bit mode
"buf3": "0xFFFFFF04",
"buf4": "0xFFFFFF05",
"buf5": "0xFFFFFF06",
"buf6": "0xFFFFFF07",
"buf7": "0xFFFFFF08",
"buf8": "0xFFFFFF09",
"buf9": "0xFFFFFF00",
},
},

"cfg3": { // XCCELA AP25616 32M PSRAM
"common": {
"clock": "198000000",
"cs0_pins": "0x0",
"cs1_pins": "0x0",
"xspi_ctl": "0x116d",
"xspi_tcr": "0x280011",
"xspi_cfg": "0x03000001",
"xspi_ldo": "0x17", //1.92V
"psram_cfg0": "0x03030304", //cmd_lines, addr_lines, data_lines, addr_width
"psram_cfg1": "0x02000001",
"xspi_cs0_iocfg1": "0x02020202",
"xspi_cs0_iocfg2": "0x02020202",
"xspi_cs0_iocfg3": "0x36060405",
"xspi_cs0_iocfg4": "0x26",
"xspi_cs1_iocfg1": "0x02020202",
"xspi_cs1_iocfg2": "0x02020202",
"xspi_cs1_iocfg3": "0x36060403",
"xspi_cs1_iocfg4": "0x26",
},
"reset": {
"proto": "0xff000001",
"buf": "0x00ffffff",
},
"getid": {

"proto": "0x40040104",
"id": "0xdf8ddf8d",
"buf": "0xffffffff",
},
"init": {
"proto0": "0xc0000001", //cmd: byte[0]=0xc0; dummy: byte[1]=0x00; addr: byte[2]=0x00; len: byte[3]=0x02;
"buf0": "0x11000000",
"proto1": "0xc0000401",
"buf1": "0x20000000",
"proto2": "0xc0000801",
"buf2": "0x4c000000",
"proto3": "0xffffffff",
"buf3": "0xffffffff",
},
"xip_cfg": {
"wr_proto": "0x80070002", //cmd: byte[0]=0x80; dummy: byte[1]=0x07; addr: byte[2]=0x08; len: byte[3]=0x02;
"wr_buf": "0xffffffff",
"rd_proto": "0x00070003",
"rd_buf": "0xffffffff",
},
"backup": {
"buf0": "0x5555aaaa",
"buf1": "0xaaaa5555",
"buf2": "0x05050101", //byte0:read_hold; byte1:write_hold; byte3:axi_read_first; byte4:bit mode
"buf3": "0xFFFFFF04",
"buf4": "0xFFFFFF05",
"buf5": "0xFFFFFF06",
"buf6": "0xFFFFFF07",
"buf7": "0xFFFFFF08",
"buf8": "0xFFFFFF09",
"buf9": "0xFFFFFF00",
},
},
},

"system": {
"upgmode": { // Set PIN to enter BROM's upgrading mode
// If set upgmode_pin_cfg_reg to "0", disable bootpin detect in PBP
"upgmode_pin_cfg_reg": "0x18700080", // PINMUX REG, PA0
"upgmode_pin_cfg_val": "0x10321", // PINMUX VAL
"upgmode_pin_input_reg": "0x18700000", // INPUT VAL REG
"upgmode_pin_input_msk": "0x1", // Bit MSK
"upgmode_pin_input_val": "0x0", // Bit VAL
"upgmode_pin_pullup_dly": "500", // us
},
"uart": { // PBP's uart setting, remove uart setting to disable log in PBP
"main": {
"uart_id": "0", // UART0 for log output
"uart_tx_pin_cfg_reg": "0x18700080", // PA0
"uart_tx_pin_cfg_val": "0x335",
"uart_rx_pin_cfg_reg": "0x18700084", // PA1
"uart_rx_pin_cfg_val": "0x335",

// "uart_id": "0", // UART0 for log output
// "uart_tx_pin_cfg_reg": "0x18700E88", // PN2
// "uart_tx_pin_cfg_val": "0x324",
// "uart_rx_pin_cfg_reg": "0x18700E8C", // PN3
// "uart_rx_pin_cfg_val": "0x324",

// "uart_id": "1", // UART1 for log output
// "uart_tx_pin_cfg_reg": "0x18700090", // PA4
// "uart_tx_pin_cfg_val": "0x325",
// "uart_rx_pin_cfg_reg": "0x18700094", // PA5
// "uart_rx_pin_cfg_val": "0x325",

// "uart_id": "3", // UART3 for log output
// "uart_tx_pin_cfg_reg": "0x187004B8", // PE14
// "uart_tx_pin_cfg_val": "0x325",
// "uart_rx_pin_cfg_reg": "0x187004BC", // PE15
// "uart_rx_pin_cfg_val": "0x325",

// "uart_id": "4", // UART4 for log output
// "uart_tx_pin_cfg_reg": "0x18700198", // PB6
// "uart_tx_pin_cfg_val": "0x325",
// "uart_rx_pin_cfg_reg": "0x1870019C", // PB7
// "uart_rx_pin_cfg_val": "0x325",

// "uart_id": "5", // UART5 for log output
// "uart_tx_pin_cfg_reg": "0x18700490", // PE4
// "uart_tx_pin_cfg_val": "0x325",
// "uart_rx_pin_cfg_reg": "0x18700494", // PE5
// "uart_rx_pin_cfg_val": "0x325",
},
},
"jtag": {
"jtag_only": "0", // 1: Boot code stop in PBP after DDR init and jtag init
"main": {
"jtag_id": "0",
"jtag_do_pin_cfg_reg": "0x187000A0", // PA8
"jtag_do_pin_cfg_val": "0x338",
"jtag_di_pin_cfg_reg": "0x187000A4", // PA9
"jtag_di_pin_cfg_val": "0x338",
"jtag_ms_pin_cfg_reg": "0x187000A8", // PA10
"jtag_ms_pin_cfg_val": "0x338",
"jtag_ck_pin_cfg_reg": "0x187000AC", // PA11
"jtag_ck_pin_cfg_val": "0x338",

// "jtag_do_pin_cfg_reg": "0x1870028C", // PC3
// "jtag_do_pin_cfg_val": "0x336",
// "jtag_di_pin_cfg_reg": "0x18700284", // PC1
// "jtag_di_pin_cfg_val": "0x336",
// "jtag_ms_pin_cfg_reg": "0x18700280", // PC0
// "jtag_ms_pin_cfg_val": "0x336",
// "jtag_ck_pin_cfg_reg": "0x18700294", // PC5
// "jtag_ck_pin_cfg_val": "0x336",
},
},
},
}

离线

楼主 #3 昨天 20:24:35

xzyang
会员
注册时间： 2019-10-27
已发帖子： 29
积分： 19

Re: D133EBS更换D133ECS后烧录失败

cfg0-cfg3这4个psram配置它会都尝试一遍还是只能保留一个？

离线

#4 昨天 20:59:52

秦始皇
会员
注册时间： 昨天
已发帖子： 6
积分： 6

Re: D133EBS更换D133ECS后烧录失败

看你后面贴的 pbp_cfg.json，我觉得现在可以再收窄一点：不是“有没有配置 cfg1/cfg2”的问题，而是 PBP 实际有没有选中你这颗料对应的那一项。

日志仍然是：

can't get the psram table, return the default info

这句话如果还在，说明 PBP 早期阶段没有成功拿到/匹配到 PSRAM table。即使 json 里已经写了 cfg1/cfg2，也可能有几个地方没对上：

  1. PSRAM ID 是否真的匹配

你 cfg1 写的是：

"id": "0xdd8ddd8d"

cfg2 写的是：

"id": "0xc59ac59a"

但你板子上实际 16MB PSRAM 到底读出来是什么 ID，要先确认。PBP 如果按 ID 查表，ID 不一致就会直接 fallback default。这里建议想办法在早期 log 里把读到的 PSRAM ID 打出来，或者临时只保留/强制使用对应 cfg 测试。

  1. 重新打包后，pbp_cfg 是否真的进了镜像

这个坑挺常见：改了 pbp_cfg.json，但打包脚本实际用的是 build 目录里另一个 copy，或者 updater image 里还是旧的 table。

可以直接在最终生成的 d13x-mmc_v1.0.1.img 里搜一下几个特征值，比如：

0xdd8ddd8d
0xc59ac59a
0x5555aaaa
0xaaaa5555

如果最终 img 里搜不到，说明你改的 json 没被打进去。那就不是参数对不对的问题，而是打包链路没吃到新配置。

  1. 直接写卡和 AiBurn 不是同一条启动链

你说“重新打包固件，并直接写入到卡内，还是一样错误”。这里要分清：

  • 从 SD/MMC 正常启动时，PBP 从卡上找 table；

  • AiBurn 时，先下发 image.updater.spl，这份 updater spl 也要带/能读到同一份 table。

所以要确认 normal boot 的 pbp 和 updater spl 两边都更新了。之前 log 里掉线发生在发完 image.updater.spl 后，这个更像 updater 那份还没搞定。

  1. 先把频率降下来试

你现在 clock 还是 198MHz。XCCELA PSRAM 参数没完全确认前，可以先降到保守一点，比如 133MHz 或更低，先让 training/初始化过了。等能稳定启动/烧录后，再往回提频率。

  1. cfg1/cfg2 不要靠猜

D133ECS 是 16MB，但 16MB 下面也有 AP12816、SCKW18X12816 这类不同 ID。容量一样不代表初始化序列一样。最好按芯片丝印/读 ID 来选，不要只按“16MB”选。

我会优先做两个动作：

  • 在最终 img / updater spl 里确认 0xdd8ddd8d 或 0xc59ac59a 这些值是否真的存在；

  • 想办法打印 PBP 实际读到的 PSRAM ID。

只要这两个确认下来，问题基本就很清楚了：要么是配置没被打包进去，要么是 ID/参数不匹配。现在单看日志，PBP 还没真正用上你贴出来的这张表。

离线

楼主 #5 昨天 21:14:54

xzyang
会员
注册时间： 2019-10-27
已发帖子： 29
积分： 19

Re: D133EBS更换D133ECS后烧录失败

感谢，我尝试排查下id特征。

离线

楼主 #6 昨天 21:27:49

xzyang
会员
注册时间： 2019-10-27
已发帖子： 29
积分： 19

Re: D133EBS更换D133ECS后烧录失败

4个cfg删掉3个，只保留这个可以启动了，真坑，手册是找不到到底封了哪种型号。
"cfg0": { // XCCELA AP12816 16M PSRAM
"common": {
"clock": "198000000",
"cs0_pins": "0x0",
"cs1_pins": "0x0",
"xspi_ctl": "0x116d",
"xspi_tcr": "0x280011",
"xspi_cfg": "0x03000001",
"xspi_ldo": "0x17", //1.92V
"psram_cfg0": "0x03030304", //cmd_lines, addr_lines, data_lines, addr_width
"psram_cfg1": "0x02000001",
"xspi_cs0_iocfg1": "0x02020202",
"xspi_cs0_iocfg2": "0x02020202",
"xspi_cs0_iocfg3": "0x36060405",
"xspi_cs0_iocfg4": "0x26",
"xspi_cs1_iocfg1": "0x02020202",
"xspi_cs1_iocfg2": "0x02020202",
"xspi_cs1_iocfg3": "0x36060403",
"xspi_cs1_iocfg4": "0x26",
},
"reset": {
"proto": "0xff000001",
"buf": "0x00ffffff",
},
"getid": {

"proto": "0x40040104",
"id": "0xdd8ddd8d",
"buf": "0xffffffff",
},
"init": {
"proto0": "0xc0000001", //cmd: byte[0]=0xc0; dummy: byte[1]=0x00; addr: byte[2]=0x00; len: byte[3]=0x02;
"buf0": "0x11000000",
"proto1": "0xc0000401",
"buf1": "0x20000000",
"proto2": "0xc0000801",
"buf2": "0x4c000000",
"proto3": "0xffffffff",
"buf3": "0xffffffff",
},
"xip_cfg": {
"wr_proto": "0x80070002", //cmd: byte[0]=0x80; dummy: byte[1]=0x07; addr: byte[2]=0x08; len: byte[3]=0x02;
"wr_buf": "0xffffffff",
"rd_proto": "0x00070003",
"rd_buf": "0xffffffff",
},
"backup": {
"buf0": "0x5555aaaa",
"buf1": "0xaaaa5555",
"buf2": "0x05050101", //byte0:read_hold; byte1:write_hold; byte3:axi_read_first; byte4:bit mode
"buf3": "0xFFFFFF04",
"buf4": "0xFFFFFF05",
"buf5": "0xFFFFFF06",
"buf6": "0xFFFFFF07",
"buf7": "0xFFFFFF08",
"buf8": "0xFFFFFF09",
"buf9": "0xFFFFFF00",
},
},

离线

#7 昨天 22:56:57

秦始皇
会员
注册时间： 昨天
已发帖子： 6
积分： 6

Re: D133EBS更换D133ECS后烧录失败

xzyang 说：

cfg0-cfg3这4个psram配置它会都尝试一遍还是只能保留一个？

我理解它设计上应该是“按表尝试/匹配”，不是只能保留一个。你这个 pbp_cfg.json 里每个 cfg 都有 getid 段，里面有 proto 和 id，这明显就是给 PBP 读 PSRAM ID 后做匹配用的。

也就是说正常逻辑大概率是：

  1. PBP 先拿到 psram table；

  2. 按 cfg0、cfg1、cfg2... 去执行 reset/getid；

  3. 读出来的 ID 和 cfg 里的 id 对上，就用这一组 init/xip/backup 参数；

  4. 都对不上，再走默认参数或者报 fallback。

但你现在日志是：

can't get the psram table, return the default info

这句话更像是“表本身没拿到”，而不是“表里 cfg0-cfg3 都试完没匹配”。如果是 ID 不匹配，按理说日志会更接近 getid fail / id mismatch 这类，而不是 get psram table fail。当然具体还得看它 PBP 源码怎么写。

我建议你做两个小实验，比猜快：

实验 1：只保留 cfg1 或 cfg2

比如你板子确定是 AP12816，就只留 cfg1，其他 cfg 先删掉或注释掉重新打包。如果日志还是 can't get the psram table，那就说明不是“多 cfg 选择问题”，而是 table 没被 PBP 读到/打包进去。

实验 2：故意改一个很明显的特征值

比如把 cfg1 的 clock 临时改成一个明显不同的值，或者改 backup 里的 magic，然后在最终 img / updater spl 里搜这个值。搜不到就说明打包链路没吃到你改的 pbp_cfg.json。

还有一点要注意：AiBurn 用到的 image.updater.spl 可能和你直接写卡启动时用的 PBP/SPL 不是同一个产物。你现在两种方式都报 table fallback，就更要确认“最终被烧录/启动的那个镜像里到底有没有这张 psram table”。

所以结论：理论上 cfg0-cfg3 应该可以多组并存、按 ID 匹配；但你这个现象优先怀疑 table 没被正确打进 PBP/updater，而不是只能保留一个 cfg。

离线

页次： 1

分享链接 / 只看楼主

页脚

工信部备案：粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn


东莞哇酷科技有限公司开发