Well now I am completely stumped. Both my i854 and i855 boards both crap out with the same strange post codes. Two completely different boards and two completely different bios vendors....
i854 ------ IO: outl 0cf8 <= 8000f844 IO: inb 0cfc => 00 PCI 0:1f.0 R.44 IO: outb 0cfc <= 10 PCI 0:1f.0 R.44 IO: inw 1004 => 0000 IO: outw 0080 <= fea0 IO: outl 0cf8 <= 800000fc IO: outw 0cfc <= 0109 PCI 0:00.0 R.fc IO: outb 0080 <= 01 IO: outb 0080 <= 02 IO: outw 0080 <= eee3 --craps out after this----
i855 ------- IO: outl 0cf8 <= 8000f8a4 IO: inb 0cfc => 01 PCI 0:1f.0 R.a4 IO: outl 0cf8 <= 8000f8a4 IO: outb 0cfc <= 00 PCI 0:1f.0 R.a4 IO: inb 04b9 => 02 IO: outb 04b9 <= 03 IO: outw 0080 <= fea0 IO: outl 0cf8 <= 800000fc IO: outw 0cfc <= 0109 PCI 0:00.0 R.fc IO: outw 0080 <= eee3 --craps out after this----
Anyone ever seen these 16bit post codes before? Help?
* Joseph Smith joe@settoplinux.org [110331 23:38]:
Well now I am completely stumped. Both my i854 and i855 boards both crap out with the same strange post codes. Two completely different boards and two completely different bios vendors....
i854
IO: outl 0cf8 <= 8000f844 IO: inb 0cfc => 00 PCI 0:1f.0 R.44 IO: outb 0cfc <= 10 PCI 0:1f.0 R.44
ACPI_CNTL: enable PMBASE
IO: inw 1004 => 0000
Probably a read to PM1_CNT
IO: outw 0080 <= fea0 IO: outl 0cf8 <= 800000fc IO: outw 0cfc <= 0109 PCI 0:00.0 R.fc
undocumented in publish data sheet.
IO: outb 0080 <= 01 IO: outb 0080 <= 02 IO: outw 0080 <= eee3
So it executes some piece of code that counts on port 80, and the second or third step fails
--craps out after this----
i855
IO: outl 0cf8 <= 8000f8a4 IO: inb 0cfc => 01 PCI 0:1f.0 R.a4 IO: outl 0cf8 <= 8000f8a4 IO: outb 0cfc <= 00 PCI 0:1f.0 R.a4
Looks undocumented in the public data sheets (ICH4?)
IO: inb 04b9 => 02 IO: outb 04b9 <= 03
If PMBASE is at 0x480, this would be a write to Alternate GPI SMI Enable
IO: outw 0080 <= fea0
IO: outl 0cf8 <= 800000fc IO: outw 0cfc <= 0109 PCI 0:00.0 R.fc
Undocumented in Memory Controller
IO: outw 0080 <= eee3
Probably the same error as above.
--craps out after this----
Anyone ever seen these 16bit post codes before? Help?
They're quite common these days. Presumably eexx describes some error code. At some point the BIOS thought something is wrong with the system.
You will have to figure out where the BIOS is taking a jump to the wrong code path and make sure you satisfy its requirements.
Does this BIOS use Cache As RAM? Did you initialize the CAR region correctly?
Try enabling some of the debug flags in the lua script.
Stefan
On 03/31/2011 06:03 PM, Stefan Reinauer wrote:
- Joseph Smithjoe@settoplinux.org [110331 23:38]:
i855
IO: outl 0cf8<= 8000f8a4 IO: inb 0cfc => 01 PCI 0:1f.0 R.a4 IO: outl 0cf8<= 8000f8a4 IO: outb 0cfc<= 00 PCI 0:1f.0 R.a4
Looks undocumented in the public data sheets (ICH4?)
Yes ICH4. I believe this is GEN_PMCON_3 resume after power failure.
IO: inb 04b9 => 02 IO: outb 04b9<= 03
If PMBASE is at 0x480, this would be a write to Alternate GPI SMI Enable
yup
IO: outw 0080<= fea0
IO: outl 0cf8<= 800000fc IO: outw 0cfc<= 0109 PCI 0:00.0 R.fc
Undocumented in Memory Controller
Yes but it is listed in lspci -xxx of a good boot so I am assuming not to worry about it.
IO: outw 0080<= eee3
Probably the same error as above.
--craps out after this----
Anyone ever seen these 16bit post codes before? Help?
They're quite common these days. Presumably eexx describes some error code. At some point the BIOS thought something is wrong with the system.
You will have to figure out where the BIOS is taking a jump to the wrong code path and make sure you satisfy its requirements.
Does this BIOS use Cache As RAM? Did you initialize the CAR region correctly?
Try enabling some of the debug flags in the lua script.
Ok attached is a more verbose output of i855. Not sure if this bios uses CAR? How do I tell? So do I need to use gdb to backtrace what jumps to [eb00:1202]?
* Joseph Smith joe@settoplinux.org [110401 01:19]:
You will have to figure out where the BIOS is taking a jump to the wrong code path and make sure you satisfy its requirements.
Are you sure it's actually hanging there forever and not just waiting in a very long delay loop? Disassemble the code there and find out what it does.
Does this BIOS use Cache As RAM? Did you initialize the CAR region correctly?
The code did not set up any MTRRs, so no CAR here (yet)
Try enabling some of the debug flags in the lua script.
Ok attached is a more verbose output of i855. Not sure if this bios uses CAR? How do I tell? So do I need to use gdb to backtrace what jumps to [eb00:1202]?
Looks like the code around eb00:03a8 does that.
On Fri, 1 Apr 2011 02:19:52 +0200, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
- Joseph Smith joe@settoplinux.org [110401 01:19]:
You will have to figure out where the BIOS is taking a jump to the
wrong
code path and make sure you satisfy its requirements.
Are you sure it's actually hanging there forever and not just waiting in a very long delay loop? Disassemble the code there and find out what it does.
Well, it does seem that the writes to 0xeb are delays (they are through out the whole dump), but I could only stand the loud constant beep code for about 10 minutes. When I backtraced the i854 it was determined that it was a constant loop. But ok, I will play with gdb and see if I can find out what is jumping to 0xeb3a9. I may need some help understanding what it is that I am looking at though because I am retarded when it comes to assembly ;-)
Does this BIOS use Cache As RAM? Did you initialize the CAR region correctly?
The code did not set up any MTRRs, so no CAR here (yet)
ok that makes sense.
Try enabling some of the debug flags in the lua script.
Ok attached is a more verbose output of i855. Not sure if this bios uses CAR? How do I tell? So do I need to use gdb to backtrace what jumps to [eb00:1202]?
Looks like the code around eb00:03a8 does that.
Joseph Smith wrote:
Well now I am completely stumped. Both my i854 and i855 boards both crap out with the same strange post codes. Two completely different boards and two completely different bios vendors.... ... IO: outw 0080 <= eee3 --craps out after this----
Anyone ever seen these 16bit post codes before? Help?
Replying direct as I can't normally post to the list due to the greylisting in use.
I would make a guess that this is the Intel Memory Reference Code (MRC) as that would most likely be common between the two boards. Unfortunately I do not have access to the code in question to tell you what is going on and even if I did I probably would not be allowed to.
If this happens without SerialICE then I would hazard a guess that it does not like the memory that is fitted, are you sure you have correct memory for each board? If it only happens with SerialICE then you probably need to adjust what accesses go where and when so that the MRC will be able to correctly complete by accessing the platform RAM before switching memory accesses to QEMU RAM for speed later.
Andrew
* Andrew Goodbody andrew.goodbody@tadpole.com [110401 12:33]:
Joseph Smith wrote:
Well now I am completely stumped. Both my i854 and i855 boards both crap out with the same strange post codes. Two completely different boards and two completely different bios vendors.... ... IO: outw 0080 <= eee3 --craps out after this----
Anyone ever seen these 16bit post codes before? Help?
Replying direct as I can't normally post to the list due to the greylisting in use.
The mail went to the list just fine. Any greylisting penalty should only hit you on your first mail after not sending mail in the last month or so.
Stefan
On 04/01/2011 06:33 AM, Andrew Goodbody wrote:
Joseph Smith wrote:
Well now I am completely stumped. Both my i854 and i855 boards both crap out with the same strange post codes. Two completely different boards and two completely different bios vendors.... ... IO: outw 0080 <= eee3 --craps out after this----
Anyone ever seen these 16bit post codes before? Help?
Replying direct as I can't normally post to the list due to the greylisting in use.
I would make a guess that this is the Intel Memory Reference Code (MRC) as that would most likely be common between the two boards.
If this happens without SerialICE then I would hazard a guess that it does not like the memory that is fitted, are you sure you have correct memory for each board? If it only happens with SerialICE then you probably need to adjust what accesses go where and when so that the MRC will be able to correctly complete by accessing the platform RAM before switching memory accesses to QEMU RAM for speed later.
Hello Andrew, On the i854 it is a set-top-box design and the memory is on-board from the manufacturer. On the i855 the memory is fine and both boards boot just fine with their normal bios's. Is there a public doc on Intel Memory Reference Code (MRC) that I can learn more about it?
* Joseph Smith joe@settoplinux.org [110402 00:33]:
On the i854 it is a set-top-box design and the memory is on-board from the manufacturer. On the i855 the memory is fine and both boards boot just fine with their normal bios's. Is there a public doc on Intel Memory Reference Code (MRC) that I can learn more about it?
Unfortunately, the real home of the easter bunny and Intel's MRC are among the biggest secrets in the 'verse.
Stefan
Stefan Reinauer wrote:
- Joseph Smith joe@settoplinux.org [110402 00:33]:
On the i854 it is a set-top-box design and the memory is on-board from the manufacturer. On the i855 the memory is fine and both boards boot just fine with their normal bios's. Is there a public doc on Intel Memory Reference Code (MRC) that I can learn more about it?
Unfortunately, the real home of the easter bunny and Intel's MRC are among the biggest secrets in the 'verse.
Stefan
Indeed. This is the big issue that prevents support of modern Intel chipsets in coreboot.
What you need to do is to adapt the filters in serialice.lua so that they work for your board(s) by routing the access to the actual hardware at first and then switch to QEMU memory for speed later. The default ones are mostly specific to whatever board and BIOS they were developed on.
Best of luck, Andrew
On Mon, 04 Apr 2011 03:51:47 -0700, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Stefan Reinauer wrote:
- Joseph Smith joe@settoplinux.org [110402 00:33]:
On the i854 it is a set-top-box design and the memory is on-board from the manufacturer. On the i855 the memory is fine and both boards boot just fine with their normal bios's. Is there a public doc on Intel Memory Reference Code (MRC) that I can learn more about it?
Unfortunately, the real home of the easter bunny and Intel's MRC are among the biggest secrets in the 'verse.
Stefan
Indeed. This is the big issue that prevents support of modern Intel chipsets in coreboot.
What you need to do is to adapt the filters in serialice.lua so that they work for your board(s) by routing the access to the actual hardware at first and then switch to QEMU memory for speed later. The default ones are mostly specific to whatever board and BIOS they were developed
on.
Ok, I see how to change the filters to do one or the other or both. But how do I tell it to do "to_hw" and switch "to_qemu" at a certian point? FYI, I only care about getting past Memory Init, after that I really do not care.
Joseph Smith wrote:
Ok, I see how to change the filters to do one or the other or both. But how do I tell it to do "to_hw" and switch "to_qemu" at a certian point? FYI, I only care about getting past Memory Init, after that I really do not care.
See the section, around line 240 in the version I have here, 'Intel 82945 (reference BIOS) RAM switch' for an example.
Andrew
On Mon, 04 Apr 2011 06:20:41 -0700, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Joseph Smith wrote:
Ok, I see how to change the filters to do one or the other or both. But
how
do I tell it to do "to_hw" and switch "to_qemu" at a certian point? FYI,
I
only care about getting past Memory Init, after that I really do not
care.
See the section, around line 240 in the version I have here, 'Intel 82945 (reference BIOS) RAM switch' for an example.
ah ok thanks :-)
On 04/04/2011 10:43 AM, Joseph Smith wrote:
On Mon, 04 Apr 2011 06:20:41 -0700, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Joseph Smith wrote:
Ok, I see how to change the filters to do one or the other or both. But
how
do I tell it to do "to_hw" and switch "to_qemu" at a certian point? FYI,
I
only care about getting past Memory Init, after that I really do not
care.
See the section, around line 240 in the version I have here, 'Intel 82945 (reference BIOS) RAM switch' for an example.
ah ok thanks :-)
Well, it looks like in the lua script all ram access are already handled by the target. It does not even "switch" to qemu until ram_is_initialized. That is my whole problem is I can't even get to ram init. So I guess I need to debug it with gdb to find out why, thanks anyways.
-
Andrew Goodbody -
Joseph Smith -
Stefan Reinauer