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 dustin.harrison@sutus.com 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: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot