Hello Kyosti,
I do agree with you that it is much easier and straight forward to change
memory parameters when you are using the source agesa but it is definitely
possible to do this for the binary agesa as well. You can provide the binary
AGESA with external tables during run-time.
I do
Hi,
My host gcc is gcc version 4.6.1 (Debian 4.6.1-4). Remove -Wshadow can
walk around this problem.
diff --git a/util/cbfstool/Makefile.inc b/util/cbfstool/Makefile.inc
index 1aa9d76..a55475b 100644
--- a/util/cbfstool/Makefile.inc
+++ b/util/cbfstool/Makefile.inc
@@ -42,7 +42,7 @@ rmodobj +=
Hi,
When I build olivehillplus, I got this error:
fmd_scanner.l: In function ‘parse_integer’:
fmd_scanner.l:47: error: declaration of ‘input’ shadows a global declaration
stdout:1192: error: shadowed declaration is here
fmd_scanner.l: In function ‘copy_string’:
fmd_scanner.l:74: error:
On ke, 2015-05-13 at 10:18 +0200, Wim Vervoorn wrote:
Hello Kyosti,
I do agree with you that it is much easier and straight forward to change
memory parameters when you are using the source agesa but it is definitely
possible to do this for the binary agesa as well. You can provide the
The QEMU x86_64 Q35 fails verification as of commit
0a50d9b35334d03f13b38e21497ba0aae8b16712
The following tests failed:
ACPI_DSDT_ACCESS_FAILURE
ACPI_SSDT_ACCESS_FAILURE
DMIDECODE_ACCESS_FAILURE
CBMEM_CONSOLE_ACCESS_FAILURE
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_OBJECT_TABLE_ACCESS_FAILURE
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Stand no-re...@raptorengineeringinc.com wrote:
The QEMU x86_64 Q35 fails verification as of commit
0a50d9b35334d03f13b38e21497ba0aae8b16712
The following tests failed:
ACPI_DSDT_ACCESS_FAILURE
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin adur...@google.com wrote:
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Stand no-re...@raptorengineeringinc.com wrote:
The QEMU x86_64 Q35 fails verification as of commit
0a50d9b35334d03f13b38e21497ba0aae8b16712
The
Sorry for not adding a subject to this thread - realized the second after I
hit send :)
I made some progress by manually adding IOAPIC #4 (assuming its address is
fixed) - Linux kernel does not panic anymore and some IRQ routing started
working, but there are still some issues.
I'm still
Hi Greg,
That is the reset vector, i.e. something going seriously wrong on the
very first instruction executed. rom image being garbage or something
like that. Check your build environment. Broken toolchain? Disk full?
Thanks for the help. I figured out there was something wrong with my
On 05/13/2015 12:31 PM, Timothy Pearson wrote:
On 05/13/2015 09:56 AM, Aaron Durbin via coreboot wrote:
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbinadur...@google.com wrote:
All those are empty including dmesg. Was this a flaky test run?
Yes it was, and of course it happened overnight. I
The ASUS KFSN4-DRE fails verification as of commit
e7db9dd2a0d42e48186f98a43221cb97051c0cdc
The following tests failed:
CBMEM_OBJECT_TABLE_TRUNCATED
Commits since last successful test:
e7db9dd 3rdparty/blobs: Move submodule marker forward
3dc60c5 vboot: fix die() hang for recovery path
a6a566b
On 05/13/2015 09:56 AM, Aaron Durbin via coreboot wrote:
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbinadur...@google.com wrote:
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Standno-re...@raptorengineeringinc.com wrote:
The QEMU x86_64 Q35 fails verification as
Hi,
I'm looking for a little advice (or steering in the right direction) in
regards to IOAPICs and how Coreboot manages detection. I have two MCP-55
chipsets just like the nVidia l1_2pvv board.
When I boot Linux under the *vendor bios* with apic debugging enabled, I
can see that I have two
13 matches
Mail list logo
