On 15/04/2010 2:18 PM, Ed Swierk wrote:
On Thu, Apr 15, 2010 at 2:04 PM, Dustin Harrison dustin.harrison@sutus.com wrote:
Yes -- I did the following: # rm .xcompile # cd util/crossgcc # ./buildgcc # cd ../../ # make clean; make
I also printed out the $(CC) variable in the Makefile to confirm: CC = CCACHE_COMPILERCHECK=content /home/dharrison/code/coreboot.trunk/util/crossgcc/xgcc/bin/i386-elf-gcc -Wa,--divide -fno-stack-protector -Wl,--build-id=none
Question: I thought I read somewhere the ROMCC is no longer used? Is that true for the entire project? Because I see that ROMCC is still used for romstage.c
I don't know the status of romcc, but it wouldn't be a shock to discover that a bug has crept into romcc, or the Truxton mainboard code, or the i3100 southbridge code.
I'd recommend you try building a revision of Coreboot from around the time I committed the Truxton code (http://tracker.coreboot.org/trac/coreboot/changeset/3656/trunk).
Good suggestion - So I've built coreboot-v2 and I can now get to the "Jumping to coreboot" line. Looking at older posts it appears that Arnaud had to play with some RAM settings to get past this issue, so I'll start there.
Tomorrow I'll have a look at the difference between the assembly code generated and see if there is anything obvious.
Would it be possible for me to download the build directory from the automated build&test server?
You'd have to ask on the list.
My apologies -- I meant to post the reply to the list.
On Thu, Apr 15, 2010 at 2:04 PM, Dustin Harrison
Question: I thought I read somewhere the ROMCC is no longer used? Is that true for the entire project? Because I see that ROMCC is still used for romstage.c
I don't know the status of romcc, but it wouldn't be a shock to discover that a bug has crept into romcc, or the Truxton mainboard code, or the i3100 southbridge code.
I'd recommend you try building a revision of Coreboot from around the time I committed the Truxton code (http://tracker.coreboot.org/trac/coreboot/changeset/3656/trunk).
Good suggestion - So I've built coreboot-v2 and I can now get to the "Jumping to coreboot" line. Looking at older posts it appears that Arnaud had to play with some RAM settings to get past this issue, so I'll start there.
Tomorrow I'll have a look at the difference between the assembly code generated and see if there is anything obvious.
I tried to compare the assembly output in coreboot-v2 rev3656 and coreboot rev:trunk. r3656 gets as far as jumping to coreboot and hangs which I have determined is due to my RAM settings. However, after applying the patch Ed sent me, coreboot trunk hangs at the "dump_spd_registers" line 280 in mainboard/intel/jarrell/debug.c:
279: print_debug("dimm "); 280: print_debug_hex8(device);
Doing a visual diff of auto.inc and romstange.inc I can see that the while loop that the above lines are contained within compiled to assembly differently between the two versions, however I went back to svn rev 4051 of romcc and built trunk and this made no difference. So it seems the problem lies somewhere in the include files.
I need to focus on my ram settings right now so I can at least move forward with rev3656, but if anyone has some ideas I'll give them a shot in between hacking the RAM.
Cheers Dustin
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
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
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
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
On 4/24/10 4:52 AM, Dustin Harrison wrote:
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
Unfortunately that does not mean much.. Qemu emulates an i440BX chipset (more or rather less) and trying to execute the BIOS of any other machine on it may or may not crash, but will not give any useful results either way.
Stefan
On 22/04/2010 11:16 AM, Dustin Harrison wrote:
When I get done with my RAM timing I'll try an svn bisect to narrow it down.
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
Cheers Dustin
Am 26.04.2010 08:24, schrieb Dustin Harrison:
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
Such flags are set in Kconfig, and there the CONFIG_ prefix isn't used.
See for example src/cpu/intel/model_6ex/Kconfig. It has "select SSE2", which enables CONFIG_SSE2 for that CPU.
Patrick
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
Thanks, Myles
On 4/26/10 3:34 PM, Myles Watson wrote:
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
There is no specific instruction in our code causing this, but a hard code of ROMCCFLAGS in mainboard/intel/truxton/Makefile.inc:
ROMCCFLAGS := -mcpu=p4 -fno-simplify-phi -O2
Dustin, can you please try if the latest revision works for you after you delete that line?
Thanks Stefan
On Mon, Apr 26, 2010 at 7:43 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 4/26/10 3:34 PM, Myles Watson wrote:
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
There is no specific instruction in our code causing this, but a hard code of ROMCCFLAGS in mainboard/intel/truxton/Makefile.inc:
I forgot that romcc was using the SSE registers.
ROMCCFLAGS := -mcpu=p4 -fno-simplify-phi -O2
Without the line it fails to build.
It builds with this line: ROMCCFLAGS += -fno-simplify-phi
With this line it fails to allocate enough registers: ROMCCFLAGS := -fno-simplify-phi -O2
Thanks, Myles
Eric,
do you have a hint what could cause romcc to produce incorrect code without -fno-simplify-phi ?
Stefan
On 4/26/10 4:23 PM, Myles Watson wrote:
On Mon, Apr 26, 2010 at 7:43 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 4/26/10 3:34 PM, Myles Watson wrote:
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
There is no specific instruction in our code causing this, but a hard code of ROMCCFLAGS in mainboard/intel/truxton/Makefile.inc:
I forgot that romcc was using the SSE registers.
ROMCCFLAGS := -mcpu=p4 -fno-simplify-phi -O2
Without the line it fails to build.
It builds with this line: ROMCCFLAGS += -fno-simplify-phi
With this line it fails to allocate enough registers: ROMCCFLAGS := -fno-simplify-phi -O2
Thanks, Myles
On 4/26/10 3:34 PM, Myles Watson wrote:
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
Thanks, Myles
If possible we should also drop these romcc hard codes:
./dell/s1850/Makefile.inc:ROMCCFLAGS := -mcpu=p4 -O2 ./intel/jarrell/Makefile.inc:ROMCCFLAGS := -mcpu=p4 -O2 ./intel/mtarvon/Makefile.inc:ROMCCFLAGS := -mcpu=p4 -O2 ./intel/xe7501devkit/Makefile.inc:ROMCCFLAGS := -mcpu=p4 -O2 ./supermicro/x6dai_g/Makefile.inc:ROMCCFLAGS=-mcpu=p4 -O2 ./supermicro/x6dhe_g/Makefile.inc:ROMCCFLAGS=-mcpu=p4 -O2 ./supermicro/x6dhe_g2/Makefile.inc:ROMCCFLAGS=-mcpu=p4 -O2 ./supermicro/x6dhr_ig/Makefile.inc:ROMCCFLAGS=-mcpu=p4 -O2 ./supermicro/x6dhr_ig2/Makefile.inc:ROMCCFLAGS=-mcpu=p4 -O2
On 26/04/2010 6:34 AM, Myles Watson wrote:
The problem with Truxton booting in trunk seems to have appeared in the migration to the new Makefile system.
If I drop a CONFIG_SSE=y into the .config file using a trunk build I can boot!
However, I don't really see how this flag gets set. Doing a 'grep -RH CONFIG_SSE' points to the two makefile includes that add the enable_sse code, but no references to setting the flag.
I added it in 5505. I think we should put an #error in the file that uses these instructions if CONFIG_SSE isn't set.
Should we add support for MMX and SSE2 also?
I have also found another issue which I run out of heap space while the PCI resource structures are being malloc'ed. Doubling the heap size solves the issue.
Here are the patches I am currently using: Index: src/cpu/intel/ep80579/Kconfig =================================================================== --- src/cpu/intel/ep80579/Kconfig (revision 5505) +++ src/cpu/intel/ep80579/Kconfig (working copy) @@ -1,3 +1,5 @@ config CPU_INTEL_EP80579 bool + select MMX select SSE + select SSE2 Index: src/mainboard/intel/truxton/Kconfig =================================================================== --- src/mainboard/intel/truxton/Kconfig (revision 5505) +++ src/mainboard/intel/truxton/Kconfig (working copy) @@ -47,3 +47,8 @@ int default 4 depends on BOARD_INTEL_TRUXTON + +config HEAP_SIZE + hex + default 0x8000 + depends on BOARD_INTEL_TRUXTON
-
Dustin Harrison -
Dustin Harrison -
Myles Watson -
Patrick Georgi -
Peter Stuge -
Stefan Reinauer -
Stefan Reinauer