+- WeHack BBS (https://bbs.wehack.space)
+-- 版块： 计算机技术 (https://bbs.wehack.space/forum-5.html)
+--- 版块： 固件技术讨论区 (https://bbs.wehack.space/forum-8.html)
+--- 主题： 通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 (/thread-240.html)
通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 - waitlamp - 04-04-2021
我有一台Chromebook Pro ( SAMSUNG XE510C24, 设备代号 Caroline ，谷歌主板代号 Glados) ，奈何 4GB 的运行内存在 Windows 下实在力不从心，遂寻找升级内存的办法
因为 Chromebook 本身依靠 coreboot 引导，甚至可以在 Chromium OS 的 Git 存储库上看到三星开发人员的提交
caroline: Adding SPD table for Samsung K4EBE304EB-EGCG (I11a1a2fc) · Gerrit Code Review (googlesource.com)
但似乎仅仅在 makefile.inc 增加了新的 spd hex 文件
升级板载内存的话，51NB 就曾有人对 XPS 板载的 DDR4 颗粒进行了更换并取得成功
Chromebook Pro 同样有Core M7 + 16GB 的高配版本，虽然很罕见，但的确存在，
还有人在 reddit 上发帖表示刷了 MrChromebox 固件（ coreboot 的定制版）并且成功运行 windows
我目前使用的是完全相同的固件
唯一不确定的，就是有说法称部分厂商会使用电阻对 SPD 进行配置
但我觉得，既然 Coreboot 是开源固件，如果有这样的识别配置，也一定可以通过修改源代码来让大容量的 SPD 识别
刚接触C，也不知天高地厚去看源码，然后就晕了
实在是代码新手，如果有任何不对的地方还请见谅
我不太明白的是
src/mainboard/google/glados/variants/caroline/Makefile.inc - coreboot - Gitiles
src/mainboard/google/glados/variants/caroline/variant.c - coreboot - Gitiles
src/mainboard/google/glados/spd/spd.c - coreboot - Gitiles
makefile.inc 决定了哪些型号的内存颗粒的 SPD hex 文件将会被编译成 spd.bin 进而编译进固件中
在 caroline 的 variant.c 的确有 gpio 配置来决定 spd_index 的值
但似乎并没有被内存初始化函数调用（或者是我太菜没看出来）
然后 CBFS 对 spd.bin 的操作也没看懂
但是内存初始化大部分似乎都被 Intel FSP 承担了
至于 DQByte MAPS 部分的话，版主发的 Intel FSP leak 刚好 leak 的是 skylake 平台的
Chromebook Pro 的处理器是 M3 6Y30
里面还正好有内存初始化的部分代码
虽然我的 Chromebook 是 Skylake 的 CoreM，但也算是对应上了
虽然文档里面有提及Memory Reference Code (MRC) 里面的 DQByte MAPS 和 Rcomp resistor
但还是看不懂，尤其是不知道 Rcomp resistor 是不是所谓配置内存的电阻
这个问题归根到底
Coreboot 的内存初始化流程是怎样的？
对于没有外置 SPD EEPROM的板载内存颗粒谁负责了容量、时序，频率的识别？Intel FSP 还是 SPD hex 文件？
Rcomp resistor 和 DQByte MAPS到底是什么？电阻/GPIO 对内存频率，时序，容量的配置是否存在？
修改 SPD Hex 文件能否起到使大容量内存被识别的作用？
（ Chromebook 几乎不可能找到硬件电路图 / 原理图，只能寄希望于对 Coreboot 的修改）
RE: 通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 - vimacs - 04-04-2021
(04-04-2021, 09:56 PM)waitlamp 提到: 唯一不确定的，就是有说法称部分厂商会使用电阻对 SPD 进行配置
但我觉得，既然 Coreboot 是开源固件，如果有这样的识别配置，也一定可以通过修改源代码来让大容量的 SPD 识别
刚接触C，也不知天高地厚去看源码，然后就晕了
实在是代码新手，如果有任何不对的地方还请见谅
我不太明白的是
src/mainboard/google/glados/variants/caroline/Makefile.inc - coreboot - Gitiles
src/mainboard/google/glados/variants/caroline/variant.c - coreboot - Gitiles
src/mainboard/google/glados/spd/spd.c - coreboot - Gitiles
makefile.inc 决定了哪些型号的内存颗粒的 SPD hex 文件将会被编译成 spd.bin 进而编译进固件中
在 caroline 的 variant.c 的确有 gpio 配置来决定 spd_index 的值
但似乎并没有被内存初始化函数调用（或者是我太菜没看出来）
然后 CBFS 对 spd.bin 的操作也没看懂
你需要看 src/mainboard/google/glados/romstage.c. 里面的 mainboard_memory_init_params() 写得很清楚：
代码:
/* Get SPD index */
const gpio_t spd_gpios[] = {
GPIO_MEM_CONFIG_0,
GPIO_MEM_CONFIG_1,
GPIO_MEM_CONFIG_2,
GPIO_MEM_CONFIG_3,
};
const int spd_idx = gpio_base2_value(spd_gpios, ARRAY_SIZE(spd_gpios));
mem_cfg->MemorySpdDataLen = SPD_LEN;
mem_cfg->DqPinsInterleaved = FALSE;
spd_memory_init_params(mupd, spd_idx);
variant_memory_init_params(mupd, spd_idx);这段代码是从4个GPIO引脚读取spd_idx，然后调用 spd_memory_init_params() (.../glados/spd/spd.c) 根据这个索引号从 CBFS 的 spd.bin 中读取 SPD. 如果你要把你的SPD填进固件的话，完全可以自己硬编码一个SPD，然后让 .../glados/spd/spd.c 里面 spd_memory_init_params() 里的 mem_cfg->MemorySpdPtr00, mem_cfg->MemorySpdPtr10 指向你的SPD数据。
(04-04-2021, 09:56 PM)waitlamp 提到: 但是内存初始化大部分似乎都被 Intel FSP 承担了
至于 DQByte MAPS 部分的话，版主发的 Intel FSP leak 刚好 leak 的是 skylake 平台的
Chromebook Pro 的处理器是 M3 6Y30
里面还正好有内存初始化的部分代码
虽然我的 Chromebook 是 Skylake 的 CoreM，但也算是对应上了
虽然文档里面有提及Memory Reference Code (MRC) 里面的 DQByte MAPS 和 Rcomp resistor
但还是看不懂，尤其是不知道 Rcomp resistor 是不是所谓配置内存的电阻
这个问题归根到底
Coreboot 的内存初始化流程是怎样的？
对于没有外置 SPD EEPROM的板载内存颗粒谁负责了容量、时序，频率的识别？Intel FSP 还是 SPD hex 文件？
Rcomp resistor 和 DQByte MAPS到底是什么？电阻/GPIO 对内存频率，时序，容量的配置是否存在？
修改 SPD Hex 文件能否起到使大容量内存被识别的作用？
（ Chromebook 几乎不可能找到硬件电路图 / 原理图，只能寄希望于对 Coreboot 的修改）
我对DRAM硬件这块不熟，我也不清楚Rcomp,dq_map,dqs_map这些概念是什么。
RE: 通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 - waitlamp - 04-05-2021
嗯，我的想法是直接修改 makefile.inc 或者 spd hex 文件
最终修改 SPD.bin 文件的 hex 文件顺序或者内容
因为 SPD.bin 实际上就是由三种内存颗粒的 SPD Hex 文件按顺序合并生成的
这样的话即便索引号没有变，CBFS 也应指向更换后的新的 SPD 信息。
不知道这样是否可行？
coreboot 关于移植的文档有介绍对于 SPD 的配置，解释了板载内存没有真正的 SPD ,而是使用存储在固件中的 SPD
https://github.com/coreboot/coreboot/blob/ffa2adf2ae3eb7bd17970acc6edb3c9397e8df4b/util/autoport/readme.md
stackoverflow 上有人详细介绍了 intel 构架 Bios 内存初始化流程，从这篇文章来看 intel 有关内存控制器的的寄存器的确是通过 SPD 设置的
https://stackoverflow.com/questions/63159663/how-does-bios-initialize-dram
还有一篇关于 coreboot 移植的笔记，也有提及 SPD 在内存初始化之前就被传递给 FSP
https://github.com/hardenedlinux/embedded-iot_profile/blob/master/docs/x86/coreboot/4.coreboot-x86%E7%A7%BB%E6%A4%8D%E7%9B%B8%E5%85%B3.md
从以上文档来看，我觉得 SPD 应该是对颗粒识别起决定性作用的
另外我觉得还可以做一点简单的测试来检验 SPD 修改是否有效，比如修改 SPD 的供应商或者型号代码，这些并不涉及时序和频率，不会对运行造成影响，但足以通过软件检验出修改是否有效
甚至可以尝试给颗粒降频，降低容量。不过手头没有编程器，怕成砖了救不回来，不敢轻易尝试
比较奇怪的是用 AIDA64 是读不出 Chromebook Pro 的 SPD 的，可能 AIDA64 是通过串口读 EEPROM, 而这个是板载内存所以读不出来
换颗粒是要寄过去换，当然就目前情况来看最坏的情况就是只识别 4GB 内存，当然乐观一点，只要颗粒在板子上总有办法可以让它识别
RE: 通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 - waitlamp - 04-05-2021
忽然发现自己菜到家了，
既然src/mainboard/google/glados/romstage.c 有这样的代码
代码:
const int spd_idx = gpio_base2_value(spd_gpios, ARRAY_SIZE(spd_gpios));那为什么不能直接用一个宏定义 把这个常量改成自己要的值呢？在 glados 的另一个设备（lars）分支中，就有这样的代码：
代码:
#define K4E6E304EB_MEM_ID 0x5代码:
/*Strengthen the Rcomp Target Ctrl for 8GB K4E6E304EB -EGCF*/
const u16 StrengthendRcompTarget[5] = { 100, 40, 40, 21, 40 };
/* Default Rcomp Target assignment */
const u16 *targeted_rcomp = RcompTarget;
/* Override Rcomp Target assignment for specific SKU(s) */
if (spd_index == K4E6E304EB_MEM_ID)
targeted_rcomp = StrengthendRcompTarget;这段代码是为了配置不同 SKU 的 RcompTarget
但既然 Caroline 没这样的代码 16GB 版本还能正常使用，姑且认为它不需要修改 RcompTarget
同样的，为了加载所需的 K4EBE304EB-EGCG 内存的 SPD 信息，因为其已包含在 spd.bin 文件中,根据 makefile.inc，只需要在src/mainboard/google/glados/romstage.c 加入类似的宏定义
代码:
#define K4EBE304EB_MEM_ID 0x2代码:
const int spd_idx = K4EBE304EB_MEM_ID;这样无论 GPIO 读出怎样的电平，SPD 都只会加载 K4EBE304EB_EGCG 的 SPD 信息
RE: 通过修改 coreboot SPD 升级板载内存的可行性？以及 Coreboot 的内存初始化流程 - vimacs - 04-05-2021
对，你要做硬件改造的话，让固件只用一个SPD就行了，用GPIO检测SPD的代码可以全部不要。
SPD就是几百字节的记录内存信息的数据，如果是内存条的话，一般就是内存条上的I2C EEPROM(i2c-tools的decode-dimms工具就是读EEPROM的内容)，板载内存的话一般就放固件里了。