[coreboot] ASRock E350M1: Boot delay with debug enabled, system RAM reported incorrectly in Linux

Scott Duplichan scott at notabs.org
Sun Jun 19 21:54:37 CEST 2011

Marshall Buschman wrote:

]Nevermind, it works - Apparently there are disadvantages to doing things 
]that require thought in the very early hours of the morning. :|

Hello Marshall,

Thanks for the update. I tested Win7 with this change and 4GB and found
it is not happy. Win7 makes a BSOD. Windbg with checked build reports:

ffffffff84126053: Store(TOM1=0xaaaaaaaa,MM1B)=0xaaaaaaaa
ffffffff8412605c: ShiftLeft(0x10000000,0x4,Local0)=0x100000000
ffffffff8412606c: Store(Local0=0x55555556,MM1L)=0x55555556
ffffffff84126072: Return(CRES=Buffer(0x42){
ffffffff84126077: }ACPI: E820 Entry 3 (type 4503599627370497)
(c7fee00000000000-700000000) overlaps
ACPI: PCI  Entry -1431655766 Min:ffffffff00000000 Max:5555555600000000
Length:100000000 Align:0
ACPI: FATAL BIOS ERROR - Need new BIOS to fix PCI problems

Unfortunately the Win7 code that prints e820 message has an error where
the argument and format string do not match. One is long and the other
is long long. That is why the numbers are garbage. The real problem is
that the asl code for \_SB.PCI0._CRS is using uninitialized variable
TOM1. The default value of aaaaaaaa from from line 267 of
family14/ssdt.asl is being used.

Somehow the OS does need to know where the PCI hole can safely start.
It can't start immediately after the end of low ram because of uma.
\_SB.PCI0._CRS is one way to pass this information. This method requires
passing data from coreboot to asl, which is a pain. I wonder if just
reserving the uma range in the e820 map is sufficient? I will try to
do some experiments tonight.

If you can send me a binary or otherwise let me recreate the serial
logging problem, I will take a look.


More information about the coreboot mailing list