What is the difference between fadt rev 3 and rev 1

[Bao, Zheng]

Hi,
My bimini board now can boot linux to login, with the sb800 code in
trunk. But I have to change the fadt->revision to 1. I am so confused.
Why this field can affect my linux booting. If I have to change it back
to 3, what else should I do to make it run correctly?

Attachments are the dmesg of 2 cases.

Zheng

[Scott Duplichan]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Friday, January 21, 2011 02:53 AM
To: [e-mail]
Subject: [coreboot] What is the difference between fadt rev 3 and rev 1

]Hi,
]My bimini board now can boot linux to login, with the sb800 code in
]trunk. But I have to change the fadt->revision to 1. I am so confused.
]Why this field can affect my linux booting. If I have to change it back
]to 3, what else should I do to make it run correctly?
]
]Attachments are the dmesg of 2 cases.
]
]Zheng

Hello Zheng,

Sorry about the FADT trouble. I believe this is the reason the version was changed:

----------
   Running a checked build of Windows is needed for understanding
   its various BIOS related BSODs. Win7 checked build complains
   when running coreboot+seabios:

FADT revision inconsistent with length.
       Revision:        0x1
       Length:          0xf4
       Expected Length: 0x74

The following patch solves the problem. Tested on Mahogany_fam10 only.
   ----------

The 3.0 version of FADT adds a few new items to the end of the version
10. FADT:

reset_reg
reset_value
x versions of address fields for supporting 64-bit addresses.

The two log files show more differences that the FADT reset
field would explain, it seems like. Is the FADT revision the
only difference in the two coreboot builds?

Thanks,
Scott

[Gregg Levine]

On Fri, Jan 21, 2011 at 10:33 AM, Scott Duplichan  wrote:
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Bao, Zheng
> Sent: Friday, January 21, 2011 02:53 AM
> To: [e-mail]
> Subject: [coreboot] What is the difference between fadt rev 3 and rev 1
>
> ]Hi,
> ]My bimini board now can boot linux to login, with the sb800 code in
> ]trunk. But I have to change the fadt->revision to 1. I am so confused.
> ]Why this field can affect my linux booting. If I have to change it back
> ]to 3, what else should I do to make it run correctly?
> ]
> ]Attachments are the dmesg of 2 cases.
> ]
> ]Zheng
>
> Hello Zheng,
>
> Sorry about the FADT trouble. I believe this is the reason the version was changed:
>
> ----------
>   Running a checked build of Windows is needed for understanding
>   its various BIOS related BSODs. Win7 checked build complains
>   when running coreboot+seabios:
>
> FADT revision inconsistent with length.
>       Revision:        0x1
>       Length:          0xf4
>       Expected Length: 0x74
>
> The following patch solves the problem. Tested on Mahogany_fam10 only.
>   ----------
>
> The 3.0 version of FADT adds a few new items to the end of the version
> 10. FADT:
>
> reset_reg
> reset_value
> x versions of address fields for supporting 64-bit addresses.
>
> The two log files show more differences that the FADT reset
> field would explain, it seems like. Is the FADT revision the
> only difference in the two coreboot builds?
>
> Thanks,
> Scott

Hello!
Scott I must say this is great work so far. But what is this "checked
build of Windows 7" you are working with here? What does it do
differently say then what this one year old laptop is running?

-----
Gregg C Levine [e-mail]
"This signature fought the Time Wars, time and again."

[Scott Duplichan]

]Hello!
]Scott I must say this is great work so far. But what is this "checked
]build of Windows 7" you are working with here? What does it do
]differently say then what this one year old laptop is running?
]
]-----
]Gregg C Levine [e-mail]
]"This signature fought the Time Wars, time and again."

Hello Greg,

The Win7 checked build includes several features that trade performance
for debug capability, when compared to the normal release build. One
item the checked build includes is enabling of many ASSERT() calls. The
Win7 checked build FADT fail is from an ASSERT(). It finds the FADT header
rev field states 3.0, yet the FADT header length field matches 1.0. All
OS release versions accept this inconsistency. I wanted to resolve it
because the checked build is useful when debugging Win7 problems with
coreboot. That ASSERT fail makes it next to impossible to run the Win7
checked build with coreboot.

When thwe FADT rev and length are inconsistent in this way, what does 
the OS do? possibilities are:

1) Ignore the FADT
2) Treat it as FADT 1.0
3) Treat it as FADT 3.0

Apparently linux treats the FADT as 3.0 in this situation. I am not
sure how Windows handles it. A possible experiment is to change the
FADT rev and length so that they both match rev 1.0. Another is to
keep it as 3.0, and double check the values of the new items it the
3.0 table.

Thanks,
Scott