xzyang 说：
cfg0-cfg3这4个psram配置它会都尝试一遍还是只能保留一个？
我理解它设计上应该是“按表尝试/匹配”，不是只能保留一个。你这个 pbp_cfg.json 里每个 cfg 都有 getid 段，里面有 proto 和 id，这明显就是给 PBP 读 PSRAM ID 后做匹配用的。
也就是说正常逻辑大概率是：
PBP 先拿到 psram table；
按 cfg0、cfg1、cfg2... 去执行 reset/getid；
读出来的 ID 和 cfg 里的 id 对上，就用这一组 init/xip/backup 参数；
都对不上，再走默认参数或者报 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。
xichuangxue 说：
这个有用，我之前在esp32+lcd弄过，直接在浏览器端把图片解码为raw data传输，esp32收到后直接写入LCD。
即省了解码，又省了内存。
对，就是这个思路。价签这种场景其实非常适合把“脏活”丢给浏览器：浏览器有 canvas，解码、缩放、旋转、抖动都很方便，板端只收最终数据。
如果继续往下做，我觉得可以直接定义一个很简单的上传格式，比如：
magic + width + height + format + payloadpayload 就是已经处理好的屏幕数据。比如：
彩屏：RGB565 little-endian，板端直接 memcpy / write framebuffer；
黑白/灰阶屏：浏览器端先做二值化或 Floyd-Steinberg 抖动，板端只负责刷屏；
如果屏幕需要特殊 bit 排列，也尽量在浏览器端排好，别让 F1C100S 再倒腾。
这样板端 http server 的逻辑会很干净：
收 header，检查宽高和 format；
分块接收 payload；
写到 framebuffer 或者临时文件；
通知显示线程刷新。
甚至可以做两个接口：
/upload_raw 上传最终屏幕数据
/upload_preview 浏览器预览用这样调试体验会很好：网页上先预览“实际会显示成什么样”，确认没问题再发给价签。
2.4G WiFi 慢这个问题，如果传 raw 数据反而更可控。比如 800x480 RGB565 大概 750KB，黑白屏就更小；如果浏览器端再做 RLE 这种简单压缩，价签类图片大面积纯色很多，压缩率应该还不错。板端解 RLE 比解 JPG 轻多了。
我觉得你这个项目挺有意思，方向是对的：让浏览器当“图像处理工作站”，F1C100S 当“网络屏幕控制器”。这样小板子压力小，代码也容易稳定。
最近翻了一下全志平台里和 HDMI 相关的问题，感觉这类问题表面看是“屏不亮/无信号”，实际经常不是 HDMI 这一层单独坏了，而是显示链路里某一环没接上。这里整理一下排查思路，方便后面遇到类似问题少走弯路。
全志平台一般不是只开一个 hdmi 节点就完事，前面还有 DE/TCON/disp 这一串。屏不亮时，先别急着改 HDMI 参数，建议先看启动日志里有没有这些信息：
disp/DE 是否初始化成功
TCON 是否绑定到 HDMI 输出
HDMI PHY 是否 enable
最终输出模式是 720p/1080p 还是默认 fallback
如果 DE/TCON 没起来，HDMI 后面再怎么调也不会有图。
常见要核对：
hdmi / hdmi-phy 节点 status 是否 okay
tcon、mixer/de、display-engine 相关节点是否打开
clock/reset 是否完整
pinctrl 里 HPD/DDC 相关引脚有没有配对
电源域/regulator 是否被裁掉
有些板子原理图上 HDMI 5V、HPD、DDC 是经过电平转换或开关管的，DTS 里如果少了 GPIO/regulator，现象就会很像“线插了但系统不知道”。
HDMI 调试建议把 HPD 和 EDID 拆开看：
HPD 不对：系统可能认为没插显示器；
HPD 对了但 EDID 读不到：一般是 DDC/I2C、上拉、电平转换、线材、显示器兼容性问题；
EDID 能读到但无图：再看 mode、pixel clock、PHY、TCON/DE 数据流。
有条件的话，用示波器/逻辑分析仪看一下 DDC 的 SCL/SDA，有时候比盯半天 dmesg 快。
一上来别直接 1080p60 拉满。建议先固定一个保守模式，例如 720p60 或 1024x768，确认链路通了再往上调。
如果某些显示器能亮、某些不亮，优先怀疑 EDID 解析/模式选择/PHY 参数边界，而不是单纯“HDMI 驱动坏”。
有的项目要求开机 logo，U-Boot 阶段就要点 HDMI；有的只要求进 Linux 后显示。两边配置不一定共用：
U-Boot 能亮，Linux 不亮：查内核 DTS/DRM/disp 配置；
U-Boot 不亮，Linux 能亮：查 U-Boot 显示驱动和板级配置；
两边都不亮：先回到供电、HPD、DDC、clock/reset 这些基础项。
我一般会这样排：
确认 HDMI 5V 输出、HPD 电平；
看内核 log，确认 HDMI/PHY/DE/TCON 是否 probe 成功；
读 EDID，看 DDC 是否通；
固定 720p60 输出；
再调分辨率、音频、热插拔；
最后才考虑改 PHY/timing 细节。
简单说，HDMI “无信号”不要只盯一个 hdmi 节点。全志平台显示链路比较长，DTS、clock/reset、HPD、DDC、EDID、TCON/DE 任一环断了，最后表现都可能是黑屏。先把链路拆开验证，定位会快很多。
看你后面贴的 pbp_cfg.json，我觉得现在可以再收窄一点：不是“有没有配置 cfg1/cfg2”的问题，而是 PBP 实际有没有选中你这颗料对应的那一项。
日志仍然是：
can't get the psram table, return the default info这句话如果还在，说明 PBP 早期阶段没有成功拿到/匹配到 PSRAM table。即使 json 里已经写了 cfg1/cfg2，也可能有几个地方没对上：
PSRAM ID 是否真的匹配
你 cfg1 写的是：
"id": "0xdd8ddd8d"cfg2 写的是：
"id": "0xc59ac59a"但你板子上实际 16MB PSRAM 到底读出来是什么 ID，要先确认。PBP 如果按 ID 查表，ID 不一致就会直接 fallback default。这里建议想办法在早期 log 里把读到的 PSRAM ID 打出来，或者临时只保留/强制使用对应 cfg 测试。
重新打包后，pbp_cfg 是否真的进了镜像
这个坑挺常见：改了 pbp_cfg.json，但打包脚本实际用的是 build 目录里另一个 copy，或者 updater image 里还是旧的 table。
可以直接在最终生成的 d13x-mmc_v1.0.1.img 里搜一下几个特征值，比如：
0xdd8ddd8d
0xc59ac59a
0x5555aaaa
0xaaaa5555如果最终 img 里搜不到，说明你改的 json 没被打进去。那就不是参数对不对的问题，而是打包链路没吃到新配置。
直接写卡和 AiBurn 不是同一条启动链
你说“重新打包固件，并直接写入到卡内，还是一样错误”。这里要分清：
从 SD/MMC 正常启动时，PBP 从卡上找 table；
AiBurn 时，先下发 image.updater.spl，这份 updater spl 也要带/能读到同一份 table。
所以要确认 normal boot 的 pbp 和 updater spl 两边都更新了。之前 log 里掉线发生在发完 image.updater.spl 后，这个更像 updater 那份还没搞定。
先把频率降下来试
你现在 clock 还是 198MHz。XCCELA PSRAM 参数没完全确认前，可以先降到保守一点，比如 133MHz 或更低，先让 training/初始化过了。等能稳定启动/烧录后，再往回提频率。
cfg1/cfg2 不要靠猜
D133ECS 是 16MB，但 16MB 下面也有 AP12816、SCKW18X12816 这类不同 ID。容量一样不代表初始化序列一样。最好按芯片丝印/读 ID 来选，不要只按“16MB”选。
我会优先做两个动作：
在最终 img / updater spl 里确认 0xdd8ddd8d 或 0xc59ac59a 这些值是否真的存在；
想办法打印 PBP 实际读到的 PSRAM ID。
只要这两个确认下来，问题基本就很清楚了：要么是配置没被打包进去，要么是 ID/参数不匹配。现在单看日志，PBP 还没真正用上你贴出来的这张表。
最近看瑞芯微这几颗芯片，感觉如果是做带屏设备，选型时不要只盯着 CPU 跑分，显示链路和软件栈反而更容易决定项目难度。
我自己的理解大概是这样：
如果只是简单 HMI、小尺寸屏、启动速度要求高，其实不一定要上完整 Android。Linux + Qt/LVGL/Flutter embedded 这类方案会轻很多，维护也省心。
RK3568 比较适合网关 + 显示 + 多媒体这种中等复杂度场景，接口比较均衡，成本和资料也相对好找。做工业屏、控制面板、轻量 NVR 之类都还挺顺手。
RK3399 性能强一些，但功耗、散热、板子复杂度也上去了。如果只是点一个 7 寸屏再跑几个页面，可能有点“杀鸡用龙刀”。当然如果要浏览器、多任务、复杂 UI，那它还是舒服。
显示接口这块要提前确认：RGB、LVDS、MIPI-DSI、HDMI 看起来都能接屏，但驱动、dts、背光、reset、供电时序、触摸这些细节才是坑。尤其是换屏时，很多问题不是内核不能驱，而是 panel timing / init sequence / reset 时序没对上。
量产角度建议一开始就把启动时间、掉电保护、rootfs 只读、OTA、看门狗这些考虑进去。开发板 demo 能跑和产品稳定跑一年，中间差的不是一两行 dts。
如果是新项目，我会先确定三件事：屏接口、系统形态、长期供货。芯片性能反而排第四。毕竟 UI 卡一点还能优化，屏点不亮是真的能把人点麻。