+- WeHack BBS (https://bbs.wehack.space)
+-- 版块： 计算机技术 (https://bbs.wehack.space/forum-5.html)
+--- 版块： 固件技术讨论区 (https://bbs.wehack.space/forum-8.html)
+--- 主题： 前几天发现 Haswell 的板子可以用 Broadwell 的 MRC 了 (/thread-374.html)
前几天发现 Haswell 的板子可以用 Broadwell 的 MRC 了 - vimacs - 12-25-2023
https://review.coreboot.org/c/coreboot/+/55496 这个修改，今年5月23日提交到上游的。前几天想尝试弄一下 Dell Latitude E7240 的固件，发现了这个选项。
以前我觉得这个不好搞，因为 Haswell 的 mrc.bin 包含了内存初始化和 PCH 初始化两部分，而 Broadwell 的 mrc.bin 只初始化内存，PCH 初始化部分放到了 refcode 里面。而现在 Angel Pons 把 PCH 初始化的代码写好了，所以现在可以用 Broadwell 的 mrc.bin 做内存初始化，然后用 native PCH init 代替 refcode.
RE: 前几天发现 Haswell 的板子可以用 Broadwell 的 MRC 了 - segfault - 01-22-2024
啊有点想歪楼～
前一阵子为了用16GB DDR3L单条内存，我也折腾过这方面。
后来基本确认了这个限制是存在于memory address decoder，配置寄存器就是字面意义地限制了单条容量，haswell、ivybridge就是只能最大8G，于是只得放弃。
现在我其实好奇另一件事情：为什么Angel Pons写的haswell native ram init提到了S3睡眠唤醒仍然有问题？我看到libreboot官网news里面提到，仍然只有闭源的MRC blob才能正常S3睡眠唤醒：
https://libreboot.org/news/libreboot20230319.html#brief-overview-of-changes
还有一件可能不太相关的事情：最近我则是在折腾ivybridge平台的dell e6430这个笔记本的S3睡眠问题。
我在coreboot的代码里插入了hexdump，通过EHCI debug打出来，然后经过观察，我现在怀疑：可能是S3睡眠的时候，DRAM没能保持供电。
证据是，我发现只要尽量快地在电源灯熄灭后立即按电源按钮唤醒，那么像是0xC0000处的oprom特有的0x55 0xAA签名，以及其他位置的数据比如VBT签名，又或者是imd root pointer magic，都会保持完好；如果多等几秒的话，那貌似就都变成随机噪声了。
不过我实在太外行太菜了……比如内存1.5V供电是不是真的在S3睡眠后就掉了，我也还没找到好的测量位点确认。
在discord的coreboot服务器讨论的时候，nic-14159他也比较赞同我的怀疑……但一方面是刚刚提过的供电是不是真的掉了还没测量确认；另一方面，呃其实我就是在搜索出现在dell官方BIOS的模块名字里的SmmEcIoDriver的时候发现了你的github～
nic的意见是，怀疑可能是dell官方的BIOS在休眠之前给EC发送了一个特殊的命令，这个命令要想知道是什么，要么嗅探LPC总线，要么就要逆向官方的BIOS或者EC固件。
说实话，逆向对我来说好像还是有点难……只能说我可以再努力挖一挖吧。
RE: 前几天发现 Haswell 的板子可以用 Broadwell 的 MRC 了 - vimacs - 01-23-2024
(01-22-2024, 09:28 PM)segfault 提到: 啊有点想歪楼～
前一阵子为了用16GB DDR3L单条内存，我也折腾过这方面。
后来基本确认了这个限制是存在于memory address decoder，配置寄存器就是字面意义地限制了单条容量，haswell、ivybridge就是只能最大8G，于是只得放弃。
现在我其实好奇另一件事情：为什么Angel Pons写的haswell native ram init提到了S3睡眠唤醒仍然有问题？我看到libreboot官网news里面提到，仍然只有闭源的MRC blob才能正常S3睡眠唤醒：
https://libreboot.org/news/libreboot20230319.html#brief-overview-of-changes
还有一件可能不太相关的事情：最近我则是在折腾ivybridge平台的dell e6430这个笔记本的S3睡眠问题。
我在coreboot的代码里插入了hexdump，通过EHCI debug打出来，然后经过观察，我现在怀疑：可能是S3睡眠的时候，DRAM没能保持供电。
证据是，我发现只要尽量快地在电源灯熄灭后立即按电源按钮唤醒，那么像是0xC0000处的oprom特有的0x55 0xAA签名，以及其他位置的数据比如VBT签名，又或者是imd root pointer magic，都会保持完好；如果多等几秒的话，那貌似就都变成随机噪声了。
不过我实在太外行太菜了……比如内存1.5V供电是不是真的在S3睡眠后就掉了，我也还没找到好的测量位点确认。
在discord的coreboot服务器讨论的时候，nic-14159他也比较赞同我的怀疑……但一方面是刚刚提过的供电是不是真的掉了还没测量确认；另一方面，呃其实我就是在搜索出现在dell官方BIOS的模块名字里的SmmEcIoDriver的时候发现了你的github～
nic的意见是，怀疑可能是dell官方的BIOS在休眠之前给EC发送了一个特殊的命令，这个命令要想知道是什么，要么嗅探LPC总线，要么就要逆向官方的BIOS或者EC固件。
说实话，逆向对我来说好像还是有点难……只能说我可以再努力挖一挖吧。
你说的这两点我都不熟，我现在在coreboot这块投入的时间很少，暂时没空探究这些东西。
Dell Latitude的笔记本，很多ACPI的方法最终都是调了SMM，所以当初我花了不少时间逆向官方固件的SMM代码，但没有找到什么有用的东西。可能最好的办法还是nic3-14159的嗅探LPC总线的做法。