Thanks for the idea Stefan.
I have yet to get SerialICE up, but I did manage to get the Truxton BIOS
into QEMU. Interesting that QEMU exceptions at the same (at least
relative to C code) spot as my board hangs. As a comparison (since so
much of the i3100 code is shared) I was able to get the MtTarvon board
up in QEMU with no crash.
Here is the output of QEMU with Truxton:
coreboot-4.0-r5422:5430M Fri Apr 23 19:46:42 PDT 2010 starting...
SMBus controller enabled
dimm qemu: fatal: triple fault
EAX=00000060 EBX=0000003c ECX=000002ff EDX=000003fd
ESI=00000020 EDI=00000035 EBP=00000050 ESP=00000050
EIP=ffff0769 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300
CS =0008 00000000 ffffffff 00cf9b00
SS =0010 00000000 ffffffff 00cf9300
DS =0010 00000000 ffffffff 00cf9300
FS =0010 00000000 ffffffff 00cf9300
GS =0010 00000000 ffffffff 00cf9300
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT= ffff0044 00000017
IDT= 00000000 0000ffff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000000 CCD=00000035 CCO=LOGICL
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000
XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000
XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000
XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000
XMM07=00000000000000000000000000000000
Aborted
On 22/04/2010 1:05 PM, Stefan Reinauer wrote:
Try tracing the original BIOS and coreboot with SerialICE and compare
the differences ... It's a bunch of work but not as ugly as debugging
ROMCC assembler output... :-) http://www.serialice.com/
Stefan
On 22.04.2010, at 20:16, Dustin Harrison <[email protected]>
wrote:
I did a diff of romstage.inc, using the same codebase (rev 5351) the
only difference between romcc 4051 and 5351 was the timestamp. This
is consistent with my finding that compiling trunk with an older
romcc didn't help the situation.
When I get done with my RAM timing I'll try an svn bisect to narrow
it down.
Unfortunately I was not as lucky as Arnaud for timing. I switched to
2T and that didn't help. Unfortunately I am using unbuffered
non-ECC SODIMMs and only have one slot unlike the truxton with ECC
DIMMs and two slots. The proprietary Truxton BIOS boots this board
so I know there is hope, just need to nail the settings.
Cheers
Dustin
On 21/04/2010 10:17 PM, Peter Stuge wrote:
Dustin Harrison wrote:
if anyone has some ideas I'll give them a shot in between hacking
the RAM.
It would be interesting to also look at output from a recent version
of romcc compiling the old code, and an old romcc compiling the new
code. That could hint to either a romcc bug or something gone bad in
the coreboot code.
//Peter
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
