the following patch was just integrated into master:
commit 6c323041f289d4453f3d97413ca402276f76f089
Author: Marc Jones <marc.jones(a)se-eng.com>
Date: Fri May 25 12:20:10 2012 -0600
Fix typo on Persimmon #if CONFIG_HAVE_ACPI_RESUME
Stupid typo: APCI instead of ACPI in Persimmon.
Change-Id: I6fd7f091cf1f5c4c0e1b57c21553dab93b545eab
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
Build-Tested: build bot (Jenkins) at Fri May 25 21:08:33 2012, giving +1
See http://review.coreboot.org/1054 for details.
-gerrit
Marc Jones (marcj303(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1054
-gerrit
commit 6c323041f289d4453f3d97413ca402276f76f089
Author: Marc Jones <marc.jones(a)se-eng.com>
Date: Fri May 25 12:20:10 2012 -0600
Fix typo on Persimmon #if CONFIG_HAVE_ACPI_RESUME
Stupid typo: APCI instead of ACPI in Persimmon.
Change-Id: I6fd7f091cf1f5c4c0e1b57c21553dab93b545eab
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
---
src/mainboard/amd/persimmon/agesawrapper.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mainboard/amd/persimmon/agesawrapper.c b/src/mainboard/amd/persimmon/agesawrapper.c
index 195ff54..779e198 100644
--- a/src/mainboard/amd/persimmon/agesawrapper.c
+++ b/src/mainboard/amd/persimmon/agesawrapper.c
@@ -253,7 +253,7 @@ UINT32 GetHeapBase(
{
UINT32 heap;
-#if CONFIG_HAVE_APCI_RESUME
+#if CONFIG_HAVE_ACPI_RESUME
/* Both romstage and ramstage has this S3 detect. */
if (acpi_get_sleep_type() == 3)
heap = (UINT32)cbmem_find(CBMEM_ID_RESUME_SCRATCH) + (CONFIG_HIGH_SCRATCH_MEMORY_SIZE - BIOS_HEAP_SIZE); /* himem_heap_base + high_stack_size */
Marc Jones (marcj303(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1054
-gerrit
commit 4db66508c3410cce30f80af03cd82d5a4960a83b
Author: Marc Jones <marc.jones(a)se-eng.com>
Date: Fri May 25 12:20:10 2012 -0600
Fix typo on PennStation #if CONFIG_HAVE_ACPI_RESUME
Stupid typo: APCI instead of ACPI in PennStation.
Change-Id: I6fd7f091cf1f5c4c0e1b57c21553dab93b545eab
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
---
src/mainboard/amd/persimmon/agesawrapper.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mainboard/amd/persimmon/agesawrapper.c b/src/mainboard/amd/persimmon/agesawrapper.c
index 195ff54..779e198 100644
--- a/src/mainboard/amd/persimmon/agesawrapper.c
+++ b/src/mainboard/amd/persimmon/agesawrapper.c
@@ -253,7 +253,7 @@ UINT32 GetHeapBase(
{
UINT32 heap;
-#if CONFIG_HAVE_APCI_RESUME
+#if CONFIG_HAVE_ACPI_RESUME
/* Both romstage and ramstage has this S3 detect. */
if (acpi_get_sleep_type() == 3)
heap = (UINT32)cbmem_find(CBMEM_ID_RESUME_SCRATCH) + (CONFIG_HIGH_SCRATCH_MEMORY_SIZE - BIOS_HEAP_SIZE); /* himem_heap_base + high_stack_size */
I'm writing this as a bug for the GMP community and CCing coreboot,
although, with the proper direction I can imagine this all ending in a
change to the configure flags in the coreboot xgcc build.
The coreboot project contains a build script for generating a cross
toolchain (xgcc). The versions were recently bumped to:
GMP_VERSION=5.0.5
MPFR_VERSION=3.1.0
MPC_VERSION=0.9
LIBELF_VERSION=0.8.13
GCC_VERSION=4.6.3
GCC_AUTOCONF_VERSION=2.64
BINUTILS_VERSION=2.22
For the purposes of this bug, the important change was the move from GMP
5.0.2 to GMP 5.0.5. The issue is that an xgcc toolchain built on one
host cannot consistently be moved to a similar operating system on a
different host with a different underlying architecture. This was seen
with both 32bit and 64bit OS installs under the following configurations:
64bit Build Host
Ubuntu 11.04 \n \l
Linux ubuntubuilder03 2.6.38-14-server #58-Ubuntu SMP Tue Mar 27
20:21:58 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
vendor_id : AuthenticAMD
model name : AMD Athlon(tm) II X4 605e Processor
64bit Execution Host
Ubuntu 10.04.3 LTS \n \l
Linux beast 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC
2010 x86_64 GNU/Linux
vendor_id : GenuineIntel
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
32bit Build Host
Ubuntu 11.04 \n \l
Linux ubuntubuilder04 2.6.38-14-generic-pae #58-Ubuntu SMP Tue Mar 27
19:06:30 UTC 2012 i686 athlon i386 GNU/Linux
vendor_id : AuthenticAMD
model name : Embedded AMD Opteron(tm) Processor 41KX HE
NOTE: The architecture is 64bit, but the operating system is 32bit
32bit Execution Host
Ubuntu 11.10 \n \l
Linux test2 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 17:34:21 UTC 2012
i686 i686 i386 GNU/Linux
vendor_id : GenuineIntel
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
The following issue symptom does not seem to be limited to Linux
operating systems. Cygwin builds using Windows XP VMs and native
Windows installs also exhibit the problem. On Linux systems, in the
coreboot build on the execution host using a tar'd and copied binary
toolchain from the build host resulted in messages like:
libpci/libpci.c:221:1: internal compiler error: Illegal instruction
make[1]: Entering directory `/home/tester/sage_edk/release_workspace/coreboot/payloads/libpayload'
CC libpci/libpci.libpci.o
Please submit a full bug report,
with preprocessed source if appropriate.
See<http://gcc.gnu.org/bugs.html> for instructions.
make[1]: Leaving directory `/home/tester/sage_edk/release_workspace/coreboot/payloads/libpayload'
make[1]: *** [build/libpci/libpci.libpci.o] Error 1
make: *** [libpayload] Error 2
or
./src/cpu/amd/agesa/cache_as_ram.inc: Assembler messages:
./src/cpu/amd/agesa/cache_as_ram.inc:67: Error: unbalanced parenthesis in operand 1.
or
romstage.c: Assembler messages:
romstage.c:476: Error: value of 4294967296 too large for field of 4 bytes at 4448
romstage.c:477: Error: value of 4294967296 too large for field of 4 bytes at 4460
<snip>
On Cygwin systems, the build resulted in messages like:
cc1: out of memory allocating 67174399 bytes after a total of 336396288
bytes
Makefile:238: recipe for target `build/console/vtxprintf.romstage.o' failed
I performed a bisect of the GMP mercurial repository and identified an
offending changeset:
http://gmplib.org:8000/gmp-5.0/rev/2b7b8ada8a20
By this, I mean, that the xgcc toolchain, when built with any change
prior to this GMP version, was able to compile coreboot when moved
between build and execution host. I constructed a patch for GMP 5.0.5
reversing this change (attached). Similarly, with this patch, the xgcc
toolchain using GMP 5.0.5 is portable.
Are the tuning changes made in this change optimal? What are the GMP
recommendations for constructing a toolchain that is portable between
similar hosts?
Thanks,
Ray
Raymond Danks
Sage Electronic Engineering, LLC
the following patch was just integrated into master:
commit 88a1ccfa55bad83429c09acdb3cb6e2aa84cb03e
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Thu May 24 13:36:30 2012 -0700
nvramtool: use C99 PRIx64 / PRId64 for uint64_t variables
In printf/printk, using %lld or %ld for uint64_t will warn on either
64bit or 32bit machines. However, C99 defines PRIx64 / PRId64 to
provide the right modifiers for printing uint64_t variables. Use them
instead.
Change-Id: I68df5d069a1e99d1a75885173ddfd7815197afea
Signed-off-by: Stefan Reinauer <reinauer(a)google.com>
Reviewed-By: Patrick Georgi <patrick(a)georgi-clan.de> at Fri May 25 08:01:34 2012, giving +2
See http://review.coreboot.org/1053 for details.
-gerrit
the following patch was just integrated into master:
commit c960958a82b43dc4401d8f300e0d90daefc9341f
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Mon May 14 13:21:08 2012 -0700
Fix size_t for certain versions of GCC
When compiling coreboot with the latest ChromeOS toolchain, GCC
complains that some printk calls use %zu in connection with size_t
types since it resolves the typedefs to long unsigned int.
The problem is solved by using the GCC built-in __SIZE_TYPE__ if it
exists and define __SIZE_TYPE__ to long unsigned int otherwise.
Change-Id: I449c3d385b5633a05e57204704e981de6e017b86
Signed-off-by: Stefan Reinauer <reinauer(a)google.com>
Reviewed-By: Patrick Georgi <patrick(a)georgi-clan.de> at Fri May 25 08:00:43 2012, giving +2
See http://review.coreboot.org/1040 for details.
-gerrit
Hello ldwer,
>>Are you using a payload? If so, which one are you using?
I use SeaBIOS stable version.
>Have you checked if there is output on the target's EHCI/serial port,
>and what the output is?
>See http://www.coreboot.org/Developer_Manual/Tools#Null-modem_cable
>and http://www.coreboot.org/EHCI_Debug_Port
I have used serial port to dump message, but it always show "▒" char, then I change baud rate 115200 to 38400, but do not help anything.
Thanks for your help.
Martin
-----Original Message-----
From: Idwer Vollering [mailto:vidwer@gmail.com]
Sent: Thursday, May 24, 2012 5:28 AM
To: martin.meng (孟憲君 - MIC)
Cc: coreboot(a)coreboot.org
Subject: Re: [coreboot] [AMD] Persimmon
2012/5/23 <martin.meng(a)mic.com.tw>:
> Hello all,
>
>
>
> I check out coreboot and build and run persimmon project via menuconfig,
Are you using a payload? If so, which one are you using?
>
> Mainborad: AMD
>
> Mainboard Model: Persimon
>
> FlashSize: 4MB
>
>
>
> But it always show 0x00 on my PCI debug card.
Have you checked if there is output on the target's EHCI/serial port,
and what the output is?
See http://www.coreboot.org/Developer_Manual/Tools#Null-modem_cable
and http://www.coreboot.org/EHCI_Debug_Port
>
> I do not know its 80 port default path is LPC or PCI, so
>
> I have tried to route 80 port to PCI in entry32.inc (src/cpu/x86/32bit),
>
> But it seem not work.
>
>
>
> Can someone help me to solve this issue,
>
>
>
> Thanks.
>
>
>
> Here is my configuration:
>
> NorthBridge: AMD family 14
>
> SouthBridge: SB800
>
> SIO: FNTEK F81865