| Submitter | Dustin Harrison |
|---|---|
| Date | 2010-04-14 20:14:59 |
| Message ID | <4BC62243.4000008@sutus.com> |
| Download | mbox | patch |
| Permalink | /patch/1236/ |
| State | Rejected |
| Headers | show |
Comments
On 14/04/2010 1:14 PM, Dustin Harrison wrote: > I am also in the process of trying my BIOS in the truxton platform, > but it will take me a while to get things up and going. In the > meantime I'm out of ideas on how to narrow this down any further. > I've tried my BIOS build on Truxton to no avail. I get stuck at the same spot. Does someone have a reference to an archive of a working Truxton build directory? At least I can start to compare differences in the assembly/.config files etc. and see if I can figure out what has gone south in my environment. Cheers Dustin
On Thu, Apr 15, 2010 at 9:53 AM, Dustin Harrison <dustin.harrison@sutus.com> wrote: > I've tried my BIOS build on Truxton to no avail. I get stuck at the same > spot. > > Does someone have a reference to an archive of a working Truxton build > directory? At least I can start to compare differences in the > assembly/.config files etc. and see if I can figure out what has gone south > in my environment. It's been a long time since I played with Truxton and I don't have a build directory sitting around, unfortunately. Have you tried building with crosstool? Using a known-good toolchain would eliminate a bunch of variables. --Ed
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 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 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 > >
Patch
Index: src/mainboard/intel/jarrell/debug.c =================================================================== --- src/mainboard/intel/jarrell/debug.c (revision 5430) +++ src/mainboard/intel/jarrell/debug.c (working copy) @@ -275,12 +275,9 @@ while(device <= SMBUS_MEM_DEVICE_END) { int status = 0; int i; - print_debug("\n"); - print_debug("dimm "); - print_debug_hex8(device); for(i = 0; (i < 256) ; i++) { - unsigned char byte; + print_debug("here now.\n"); if ((i % 16) == 0) { print_debug("\n"); print_debug_hex8(i);