+- WeHack BBS (https://bbs.wehack.space)
+-- 版块： 计算机技术 (https://bbs.wehack.space/forum-5.html)
+--- 版块： 固件技术讨论区 (https://bbs.wehack.space/forum-8.html)
+--- 主题： 疯狂的想法：官方的AMI Aptio UEFI BIOS有没有可能开启控制台调试？ (/thread-377.html)
疯狂的想法：官方的AMI Aptio UEFI BIOS有没有可能开启控制台调试？ - segfault - 01-22-2024
在调查Intel 4代及以前的平台是否支持16GB DDR3单条内存的过程中，
1.首先我是看见intelligent memory这家产内存的小厂曾经放出消息声称“这不是硬件限制，仅仅只是BIOS软件层面的问题”。
这种说法我在经过实验后基本确定移动平台上并不符合事实，这个限制应该是存在于memory address decoder之中，而且BIOS软件层面是解析SPD byte offset 5里面的列地址数目，据此进行单条粒度的软屏蔽（这一点移动平台也和桌面平台不同，移动平台被默认软屏蔽单条内存后仍然可以开机）；而并非是传言声称的“MRC在解析SPD byte offset 4的时候只要看到了代表8Gbit的0x05就呆住不动”；
然而LGA2011 IvyBridge-E平台是基本符合事实的，像华硕当年还专门在官网发了文章：
https://rog.asus.com/articles/maximus-motherboards/max-your-mem-128gb-ddr3-support-on-rampage-iv-black-edition-and-asus-x79-motherboards/
2.于是在确认了像是X79这样的平台，在硬件层面并不存在局限之后，下一个问题就是：如果主板厂商官方没能提供BIOS更新来支持16GB单条内存，是不是可以自行修改达成这个目的？
我使用IDA Pro和diaphora大致对比过IvtQpiandMrcInit模块，虽然很遗憾不同厂牌甚至不同型号的改动都不尽相同；但仍然有一点共通的修改：存在一个看上去是报错的逻辑，报错字符串是
代码:
"Error! Support for 8Gb devices has been fused off!\n"但非常遗憾，实验发现修改跳转指令后机器仍然是黑屏不能亮机……
（不过另一方面，附近还存在类似的提及4Gb的报错逻辑，如果修改跳转指令让这个报错的逻辑总是会报错、而无视实际情况，那么就实现了“只要插上SPD中标记自身是4Gbit就一样黑屏无法正常亮机”的现象。于是这也从侧面证明，移除这处报错的逻辑是必须的，只不过仍然不充分）
3.华硕可能是在production build里把报错字符串全都去除掉了。但像是微星、华擎，又或者是CLEVO蓝天，他们的BIOS里，MRC代码中貌似仍然都含有大量报错字符串。
我很好奇这些报错字符串具体都去了哪里，尤其是，有个特别狂野的想法是，有没有可能接出来让它们打到控制台里？
不过限于我对微机原理实在是野路子一窍不通，所以完全懵逼……
目前的话，我看到华擎有一款主板X79 Extreme 6/GB，自带名叫Dr.Debug的数码管，可以显示POST code。
另外非常感谢另一位网友BufferMod，实际上就是他不辞劳苦帮我实现这些折腾实验的想法。根据他的反馈，这款主板很遗憾并不能通过转接卡使用SO-DIMM笔记本DDR3内存点亮；但16GB单条内存，和更常见的8GB或更小容量的内存，停住的POST code并不一样。
我也根据这些POST code找到了高度疑似是输出这些code的函数，但还没进一步确认。
（另外他最近一阵子都有其他的事情要忙，可能暂时没时间折腾这方面了，但我还是忍不住想在这里发帖问一问）
RE: 疯狂的想法：官方的AMI Aptio UEFI BIOS有没有可能开启控制台调试？ - vimacs - 01-23-2024
这些字符串为什么会留在固件里面，有一种可能是源码里面是用某个打印过程打印的，到发布的时候只是把这个函数变成空实现了，而不是彻底把它消除掉。另一种可能是程序里面有一些assert语句，到发布版本都没有去掉，但可能在出某些错的时候才出现。
一个例子是Broadwell的refcode,可以看我链接里的这几行代码，它给一个打印函数传了个字符串的指针，字符串是存在的，但是打印函数是个空函数。
https://github.com/mytbk/r2dumpbin_ref/blob/main/librem_refcode/broadwell_refcode_librem.asm#L122