We have a customer that runs a RTOS that uses the MP Tables (rather than ACPI). They are having an issue with the RTOS not being able to determine certain system interrupt settings from the MP tables. The sent me a MPDiag utility (this may be their own MPDiag utility, I believe I've seen others) that exposes the problem. Using it I was able to determine that the mptable that coreboot generates is getting corrupted somehow by seabios. When I bisected seabios I found that there are several commits that cause the mptable corruption. The first two problem commits are ... 5DBF1732 ECA5A947 I reverted both of those commits and still had issues, so for the short term solution I just used a seabios branch based off of 4EDDA08 (which is the commit that precedes 5DBF1732) to allow the customers MPDiag to pass.
Has anybody else seen an issue like this? Anybody have any suggestions on how to approach fixing this?
Thanks, Dave
On Tue, Oct 08, 2013 at 05:27:34PM -0500, Dave Frodin wrote:
We have a customer that runs a RTOS that uses the MP Tables (rather than ACPI). They are having an issue with the RTOS not being able to determine certain system interrupt settings from the MP tables. The sent me a MPDiag utility (this may be their own MPDiag utility, I believe I've seen others) that exposes the problem. Using it I was able to determine that the mptable that coreboot generates is getting corrupted somehow by seabios. When I bisected seabios I found that there are several commits that cause the mptable corruption. The first two problem commits are ... 5DBF1732 ECA5A947
This is on coreboot, right? I don't see a commit ECA5A947 in seabios, and I don't see how 5DBF1732 could impact mptable. I guess it's possible that 5DBF1732 could impact the interrupts as we no longer run a sipi on all the processors, but I don't think SeaBIOS should have to issue a sipi - if that is doing something that impacts the OS then coreboot should do it as part of initializing the processors.
-Kevin
-
Dave Frodin -
Kevin O'Connor