Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/253
-gerrit
commit 7c934a0665195ffb523cdc05366492e7acfb0ff0
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Wed Oct 12 14:05:49 2011 -0700
Update "STABLE" SeaBIOS selection to release 1.6.3
1.6.3 has a lot of benefits over the previous version, the two
most important being:
- working AHCI support
- compiles with gcc 4.6.x
Change-Id: Ie3a4d8f2624e0aa85e48ca09da53474c085838db
Signed-off-by: Stefan Reinauer <reinauer(a)google.com>
---
payloads/external/SeaBIOS/Makefile.inc | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/payloads/external/SeaBIOS/Makefile.inc b/payloads/external/SeaBIOS/Makefile.inc
index e04ffea..99d402c 100644
--- a/payloads/external/SeaBIOS/Makefile.inc
+++ b/payloads/external/SeaBIOS/Makefile.inc
@@ -1,7 +1,7 @@
TAG-$(CONFIG_SEABIOS_MASTER)=origin/master
-TAG-$(CONFIG_SEABIOS_STABLE)=1efb10b9ea30c45a8c9c6230234fefa10d2886ed
+TAG-$(CONFIG_SEABIOS_STABLE)=e66fb31eac3e6be6aaab548c229af9bb1ba55c33
unexport KCONFIG_AUTOCONFIG
@@ -24,6 +24,7 @@ config: checkout
$(MAKE) -C seabios defconfig
echo "CONFIG_COREBOOT=y" >> seabios/.config
echo "CONFIG_DEBUG_SERIAL=y" >> seabios/.config
+ echo "CONFIG_DEBUG_SERIAL_PORT=0x3f8" >> seabios/.config
echo "CONFIG_COREBOOT_FLASH=y" >> seabios/.config
echo "CONFIG_LZMA=y" >> seabios/.config
echo "CONFIG_FLASH_FLOPPY=y" >> seabios/.config
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/252
-gerrit
commit b1305505c57e4a4c34cf7f11b7028bf52dc8fd2a
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Wed Oct 12 12:54:08 2011 -0700
Fix romstage creation with gcc 4.6 and CAR targets
newer gcc versions generate ".section .text" instead of just ".text"
in their assembler output. This patch makes sure that we don't end up
with a superfluous ".section" that makes the build fail.
Add -Wno-unused-but-set-variable to CFLAGS if the flag exists.
Change-Id: I7f24c987433cc5886dde2af27498d3331cbda303
Signed-off-by: Stefan Reinauer <reinauer(a)google.com>
---
src/arch/x86/Makefile.inc | 3 ++-
util/xcompile/xcompile | 4 ++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/arch/x86/Makefile.inc b/src/arch/x86/Makefile.inc
index e9c00de..65c2a92 100755
--- a/src/arch/x86/Makefile.inc
+++ b/src/arch/x86/Makefile.inc
@@ -247,7 +247,8 @@ $(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc: $(src)/mainboard/$(MAINBOARDD
$(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc: $(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc
@printf " POST romstage.inc\n"
- sed -e 's/\.rodata/.rom.data/g' -e 's/\.text/.section .rom.text/g' $^ > $@.tmp
+ sed -e 's/\.rodata/.rom.data/g' -e 's/\^\.text/.section .rom.text/g' \
+ -e 's/\^\.section \.text/.section .rom.text/g' $^ > $@.tmp
mv $@.tmp $@
endif
diff --git a/util/xcompile/xcompile b/util/xcompile/xcompile
index fd4dbeb..b68e1b3 100644
--- a/util/xcompile/xcompile
+++ b/util/xcompile/xcompile
@@ -79,6 +79,10 @@ CC="${GCCPREFIX}gcc"
testcc "$CC" "$CFLAGS-Wa,--divide " && CFLAGS="$CFLAGS-Wa,--divide "
testcc "$CC" "$CFLAGS-fno-stack-protector " && CFLAGS="$CFLAGS-fno-stack-protector "
testcc "$CC" "$CFLAGS-Wl,--build-id=none " && CFLAGS="$CFLAGS-Wl,--build-id=none "
+# GCC 4.6 is much more picky about unused variables. Turn off it's warnings for
+# now:
+testcc "$CC" "$CFLAGS-Wno-unused-but-set-variable " && \
+ CFLAGS="$CFLAGS-Wno-unused-but-set-variable "
if which gcc 2>/dev/null >/dev/null; then
HOSTCC=gcc
> -----Original Message-----
> From: Thomas Gstädtner [mailto:thomas@gstaedtner.net]
> Sent: Wednesday, October 12, 2011 4:10 PM
> To: Marc Jones
> Cc: She, Kerry; coreboot
> Subject: Re: [coreboot] Issues with Supermicro H8SCM
>
> On Wed, Oct 12, 2011 at 02:46, Marc Jones <marcj303(a)gmail.com> wrote:
> > On Tue, Oct 11, 2011 at 6:17 AM, Thomas Gstädtner
> <thomas(a)gstaedtner.net> wrote:
> >> On Tue, Oct 11, 2011 at 12:41, She, Kerry <Kerry.She(a)amd.com> wrote:
> >>> Hello, Thomas
> >>>
> >>>> -----Original Message-----
> >>>> From: Thomas Gstädtner [mailto:thomas@gstaedtner.net]
> >>>> Sent: Sunday, October 09, 2011 11:53 PM
> >>>> To: She, Kerry
> >>>> Cc: Marc Jones; coreboot
> >>>> Subject: Re: [coreboot] Issues with Supermicro H8SCM
> >>>>
> >>>> On Sun, Oct 9, 2011 at 07:17, She, Kerry <Kerry.She(a)amd.com> wrote:
> >>>> > Hello, Thomas
> >>>> >
> >>>> >> -----Original Message-----
> >>>> >> From: coreboot-bounces+kerry.she=amd.com(a)coreboot.org
> >>>> >> [mailto:coreboot-
> >>>> >> bounces+kerry.she=amd.com(a)coreboot.org] On Behalf Of Marc Jones
> >>>> >> Sent: Saturday, October 08, 2011 3:45 AM
> >>>> >> To: Thomas Gstädtner
> >>>> >> Cc: coreboot
> >>>> >> Subject: Re: [coreboot] Issues with Supermicro H8SCM
> >>>> >>
> >>>> >> On Fri, Oct 7, 2011 at 1:10 PM, Thomas Gstädtner
> >>>> >> <thomas(a)gstaedtner.net>
> >>>> >> wrote:
> >>>> >> >
> >>>> >> > Thanks for the advice Marc,
> >>>> >> >
> >>>> >> > I already had the loglevel set to spew (8). I additionally
> tried
> >>>> >> > the other "Verbose output" debugging options, unfortunately I
> don't
> >>>> >> > get any output at all when they are built in.
> >>>> >> > Also, while it is hard to find and AMD doesn't have any
> official
> >>>> >> > document confirming this, according to some google hits the
> >>>> >> > processor should be revision D1 not rev E (AMD model number:
> >>>> OS4170OFU6DGOWOF ).
> >>>> >
> >>>> > I also found the latest code not boot on my H8SCM-F mainboard with
> Rev
> >>>> D1 processor.
> >>>> > So I have made some update to using the AGESA wrapper framework,
> the
> >>>> > attachment is some of my update, with this series of patches
> applied,
> >>>> > we can boot to Debian Linux Destop or Windows Server 2008 R2
> standard
> >>>> > edition.
> >>>> > Thanks
> >>>> >
> >>>>
> >>>> Hi Kerry,
> >>>>
> >>>> first of all: thanks for your effort!
> >>>> While I had no success at first, I now can get to the boot prompt
> >>>> (haven't tried any further yet).
> >>>>
> >>>> Anyway, I currently have 2 DIMMs, each 4 GiB.
> >>>> A dual-channel configuration does not seem to work, the DIMMs are
> >>>> detected, but coreboot throws an "ASSERTION FAILED" error (see
> attached
> >>>> log cb_h8scm_01.log).
> >>>> It seems to fail because it somehow seems to think no DIMM is found
> >>>> (despite both DIMMs being detected). I tried disabling this check,
> but
> >>>> this only leads to a reset.
> >>>> The same problem exists with a single-DIMM configuration.
> >>>>
> >>>> However, when I switch to a dual-DIMM, single-channel config, it at
> first
> >>>> does not start at all (i.e. no output on serial and no heartbeat
> from the
> >>>> BMC) - but when I trigger a manual reset it immediately starts up
> (see
> >>>> attached log cb_h8scm_dimma1a2_success.log).
> >>>>
> >>>> I'll report back when I find out more.
> >>>
> >>>
> >>> I have only test with 4 Registered ECC DIMMs, so I can confirm dual
> DIMMs in one channel should works,
> >>> It seems that the DRAM training has some problem for single DIMM on
> one channel situation.
> >>> Thanks
> >>> Kerry
> >>>
> >>
> >> I unfortunately only have 2 registered DIMMs, so I can't test a dual
> >> channel configuration, but yes, seems 1 DIMM per Channel does not work
> >> at all.
> >>
> >> Anyway, I built a rom with vga bios included and can boot to FILO
> >> prompt or SeaBIOS. So far USB is not working, neither the attached USB
> >> keybord, nor the USB flashdrive I wanted to boot from.
> >> A related warning seems to be: "WARNING - Timeout at
> >> ehci_wait_qh:319!", might try to disable ehci to see if ohci works.
> >>
> >> Also, it seems it now starts up most of the time immediately,
> >> approximately 1 out of 5 times it needs a manual reset after powering
> >> up.
> >> Time from power-on to FILO prompt is about 2 seconds with loglevel 3
> >> (over serial, via VGA I can't tell, it's ready long before the display
> >> makes it from wake-up to active).
> >>
> >> So in short,
> >> What Works: All 6 CPU cores are detected, clock is correct, VGA,
> >> Serial, SeaBIOS and FILO
> >> What Doesn't: USB/EHCI, Single-DIMM per Channel, reliable bootup
> >>
> >> --
> >> coreboot mailing list: coreboot(a)coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >
> > Hi Tomas
> >
> > This is great feedback. Maybe you can narrow down the boot failure. Is
> > it in coreboot, payload, or Linux when it fails?
> >
> >
> >
> > Kerry,
> >
> > Please add this info to the wiki for this board.
> >
> > Thanks,
> > Marc
> >
> > --
> > http://se-eng.com
> >
>
> This is really hard to figure out so far, because I can get zero
> output that would help me debug this problem.
> I don't know how the hardware works exactly, but the board has a neat
> watchdog in the BMC that seems to give a hint.
> There's a heartbeat-LED that flashes when coreboot seems to run (when
> it flashes I usually get output on serial and VGA), and when it
> doesn't come up, the heartbeat-LED is off. So I _assume_ it is failing
> early on, no clue how the BMC is powered on or what it looks for.
The H8SCM Serial port connection is dependent on the BMC,
Some older BMC implementation require the system BIOS to waiting for the BMC initialization,
The serial console log printed by coreboot was dropped away during BMC initialize stage.
The mainbaord manual says after the BMC init was finished, the LED will blanking.
So you can power on the board after the BMC LED is blanking.
Otherwise you need the BMC datasheet to figure out a solution to waiting for the BMC initialization.
> I'm pretty sure the payload is not the problem and as I have not tried
> to load linux yet we can rule that out :)
The EHCI ports works well under Linux/windows OS,
But I get some problem with seabios payload to using the EHCI CDROM and FlashDrive.
EHCI cdrom boot sometimes, fail to boot some other time, it's quite not stable.
Thanks
> I'm happy to help with the wiki btw.
Dear coreboot folks,
on IRC Rudolf mentioned that the A8V SE [1] works with the latest
revision of coreboot and he asked if there is a way to tag that in the
repository.
There are several ways to accomplish that but all seem to have down
sides.
1. Git tags. We could use `git tag <board name> <commit>` and interested
folks could then do `git tag | grep <board name>` to find tested
revisions. Peter wrote, that Git tags could slow down the repository and
that only finitely many tags can be used. Would the last point be a
problem for us?
2. Git notes. Peter suggested also to use Git notes. But Rudolf wrote he
finds it difficult to handle.
3. Wiki. We could use the Wiki by either adding tested revisions to the
corresponding board pages or by creating a new page with a table. The
first solution is not feasible because not all boards have their own
page. Patrick wrote that using the Wiki often it gets out of date pretty
quickly. Although in this case I think that would not be a huge problem
considering that the noted revision actually was tested. Additionally
not a lot of developers are comfortable using the Wiki. OpenEmbedded
once did something like that [2].
4. Provide tested images. In addition to specifying the revision such
tested images could be uploaded somewhere so users would not have to
build it themselves. This would not work though, since the
infrastructure is not in place and we have to be careful with images
containing option roms(?).
5. ROM-o-matic.net [3]. Idwer suggested a service similar to
ROM-o-matic.net where know revisions get build by this server and users
can configure an image to be built. That is an interesting idea although
it is probably the most difficult to realize. Could this be a GSoC
project?
6. File in repository. An other suggestion by Patrick and myself is to
put a file in for example `Documentation/working-revisions.mdtext` and
note the tested revision and board there or to put a file in each board
directory and note tested revisions there. The downside is that people
would have to register with Gerrit to submit changes.
If we would manage our Wiki in our repository [4] options 3 and 6 could
be combined.
7. Messages to the list. Thinking about it the easiest solution would be
to create something like the script `alsa-info.sh`. This script collects
the necessary information – in our case for example revision, boards,
cbfs output, used build tools. Even better would be to run that script
on the tested machine so also something like the tested distribution
could be tested.
Then a mbox or text file with an appropriate name/subject line is
created
[Tested] ASUS M2V-MX SE works with revision <commit>
which gets send to the list by the user or automatically.
People then can search the archive. The only downside is that a nice
table is missing.
All in all I am quite surprised that no nice solutions seem to exist
especially since I would imagine quality assurance (QA) folks in
companies need to maintain similar data.
Please comment and add your ideas.
Thanks,
Paul
[1] http://www.coreboot.org/Supported_Motherboards
[2] http://www.openembedded.org/wiki/Testing
[3] http://rom-o-matic.net/
[4] http://www.coreboot.org/pipermail/coreboot/2011-June/065706.html
[5] http://alsa-project.org/main/index.php/Help_To_Debug
On Wed, Oct 12, 2011 at 02:46, Marc Jones <marcj303(a)gmail.com> wrote:
> On Tue, Oct 11, 2011 at 6:17 AM, Thomas Gstädtner <thomas(a)gstaedtner.net> wrote:
>> On Tue, Oct 11, 2011 at 12:41, She, Kerry <Kerry.She(a)amd.com> wrote:
>>> Hello, Thomas
>>>
>>>> -----Original Message-----
>>>> From: Thomas Gstädtner [mailto:thomas@gstaedtner.net]
>>>> Sent: Sunday, October 09, 2011 11:53 PM
>>>> To: She, Kerry
>>>> Cc: Marc Jones; coreboot
>>>> Subject: Re: [coreboot] Issues with Supermicro H8SCM
>>>>
>>>> On Sun, Oct 9, 2011 at 07:17, She, Kerry <Kerry.She(a)amd.com> wrote:
>>>> > Hello, Thomas
>>>> >
>>>> >> -----Original Message-----
>>>> >> From: coreboot-bounces+kerry.she=amd.com(a)coreboot.org
>>>> >> [mailto:coreboot-
>>>> >> bounces+kerry.she=amd.com(a)coreboot.org] On Behalf Of Marc Jones
>>>> >> Sent: Saturday, October 08, 2011 3:45 AM
>>>> >> To: Thomas Gstädtner
>>>> >> Cc: coreboot
>>>> >> Subject: Re: [coreboot] Issues with Supermicro H8SCM
>>>> >>
>>>> >> On Fri, Oct 7, 2011 at 1:10 PM, Thomas Gstädtner
>>>> >> <thomas(a)gstaedtner.net>
>>>> >> wrote:
>>>> >> >
>>>> >> > Thanks for the advice Marc,
>>>> >> >
>>>> >> > I already had the loglevel set to spew (8). I additionally tried
>>>> >> > the other "Verbose output" debugging options, unfortunately I don't
>>>> >> > get any output at all when they are built in.
>>>> >> > Also, while it is hard to find and AMD doesn't have any official
>>>> >> > document confirming this, according to some google hits the
>>>> >> > processor should be revision D1 not rev E (AMD model number:
>>>> OS4170OFU6DGOWOF ).
>>>> >
>>>> > I also found the latest code not boot on my H8SCM-F mainboard with Rev
>>>> D1 processor.
>>>> > So I have made some update to using the AGESA wrapper framework, the
>>>> > attachment is some of my update, with this series of patches applied,
>>>> > we can boot to Debian Linux Destop or Windows Server 2008 R2 standard
>>>> > edition.
>>>> > Thanks
>>>> >
>>>>
>>>> Hi Kerry,
>>>>
>>>> first of all: thanks for your effort!
>>>> While I had no success at first, I now can get to the boot prompt
>>>> (haven't tried any further yet).
>>>>
>>>> Anyway, I currently have 2 DIMMs, each 4 GiB.
>>>> A dual-channel configuration does not seem to work, the DIMMs are
>>>> detected, but coreboot throws an "ASSERTION FAILED" error (see attached
>>>> log cb_h8scm_01.log).
>>>> It seems to fail because it somehow seems to think no DIMM is found
>>>> (despite both DIMMs being detected). I tried disabling this check, but
>>>> this only leads to a reset.
>>>> The same problem exists with a single-DIMM configuration.
>>>>
>>>> However, when I switch to a dual-DIMM, single-channel config, it at first
>>>> does not start at all (i.e. no output on serial and no heartbeat from the
>>>> BMC) - but when I trigger a manual reset it immediately starts up (see
>>>> attached log cb_h8scm_dimma1a2_success.log).
>>>>
>>>> I'll report back when I find out more.
>>>
>>>
>>> I have only test with 4 Registered ECC DIMMs, so I can confirm dual DIMMs in one channel should works,
>>> It seems that the DRAM training has some problem for single DIMM on one channel situation.
>>> Thanks
>>> Kerry
>>>
>>
>> I unfortunately only have 2 registered DIMMs, so I can't test a dual
>> channel configuration, but yes, seems 1 DIMM per Channel does not work
>> at all.
>>
>> Anyway, I built a rom with vga bios included and can boot to FILO
>> prompt or SeaBIOS. So far USB is not working, neither the attached USB
>> keybord, nor the USB flashdrive I wanted to boot from.
>> A related warning seems to be: "WARNING - Timeout at
>> ehci_wait_qh:319!", might try to disable ehci to see if ohci works.
>>
>> Also, it seems it now starts up most of the time immediately,
>> approximately 1 out of 5 times it needs a manual reset after powering
>> up.
>> Time from power-on to FILO prompt is about 2 seconds with loglevel 3
>> (over serial, via VGA I can't tell, it's ready long before the display
>> makes it from wake-up to active).
>>
>> So in short,
>> What Works: All 6 CPU cores are detected, clock is correct, VGA,
>> Serial, SeaBIOS and FILO
>> What Doesn't: USB/EHCI, Single-DIMM per Channel, reliable bootup
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
> Hi Tomas
>
> This is great feedback. Maybe you can narrow down the boot failure. Is
> it in coreboot, payload, or Linux when it fails?
>
>
>
> Kerry,
>
> Please add this info to the wiki for this board.
>
> Thanks,
> Marc
>
> --
> http://se-eng.com
>
This is really hard to figure out so far, because I can get zero
output that would help me debug this problem.
I don't know how the hardware works exactly, but the board has a neat
watchdog in the BMC that seems to give a hint.
There's a heartbeat-LED that flashes when coreboot seems to run (when
it flashes I usually get output on serial and VGA), and when it
doesn't come up, the heartbeat-LED is off. So I _assume_ it is failing
early on, no clue how the BMC is powered on or what it looks for.
I'm pretty sure the payload is not the problem and as I have not tried
to load linux yet we can rule that out :)
I'm happy to help with the wiki btw.