With CONFIG_DEBUG_COVERAGE enabled, the build currently fails with
src/lib/gcov-glue.c: In function 'fseek':
src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format]
src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format]
Change-Id: Iddaa601748c210d9dad06ae9dab2a3deaa635b2c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3032
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change modifies the code in libpayload that scans the PCI hierarchy for
USB controllers. Previously, if a devices primary function (function 0) was a
bridge, then none of the other functions, if any, would be looked at. If one
of the other functions was a bridge, that wouldn't be handled either. The new
version looks at each function that's present no matter what, and if it
discovers that it's a bridge it scans the other side.
Change-Id: I37f269a4fe505fd32d9594e2daf17ddd78609c15
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2517
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds condition codes when using the msr instruction. Although
described as "optional" in the Cortex-A series programmer's guide,
our experience with using the msr instruction in the payload suggests
that the condition code is not optional and that this only worked
in coreboot (and u-boot) because the processor comes up in SVC32 mode.
(credit to Gabe Black for finding this, I'm only uploading the patch)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b
Reviewed-on: http://review.coreboot.org/3037
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a missing address-of operator. This was a subtle bug that
didn't seem to cause problems at first since the serial console
appeared to work. However it caused an imprecise external abort which
became apparent later on when aborts were unmasked in the kernel via
the CPSR_A bit.
(credit goes to Gabe Black for finding this)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea
Reviewed-on: http://review.coreboot.org/3038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Display hardware is part of this SOC, and we need to be able
to set certain variables in devicetree.cb. This chip file
contains the initial things we think we need to set.
Change-Id: I16f2d4228c87116dbeb53a3c9f3f359a6444f552
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3031
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Explicitly call out the effects of hyperthreads running the
MTRR code and its impact on the enablement of ROM caching.
Change-Id: I14b8f3fdc112340b8f483f2e554c5680576a8a7c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3018
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes at least one warning on my machine where "llx" is replaced by PRIx64.
Change-Id: Iee3e5027d327d4d5f8e6d8b2d53d051f74bfc354
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3024
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Cppcheck [1], a static code analysis tool, warns about the
following.
$ cppcheck --version
Cppcheck 1.59
$ cppcheck --enable=all .
[…]
Checking cpu.c...
[cpu.c:951]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[cpu.c:962]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[…]
And indeed, `core` is an unsigned integer and `man 3 printf` tells
the following about conversion specifiers.
d, i The int argument is converted to signed decimal notation. […]
o, u, x, X
The unsigned int argument is converted to unsigned octal (o), unsigned decimal (u), or unsigned hexadecimal (x and X)
notation.
So use `u` and Cppcheck does not complain anymore.
[1] http://cppcheck.sourceforge.net/
Change-Id: If8dd8d0efe75fcb4af2502ae5100e3f2062649e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3026
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When building inteltool under x86-32, the following warnings are
shown.
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
Nico Huber commented the following [1].
I don't see those warnings because I build for x86-64. I guess
they could be fixed by casting to `ptrdiff_t` (from stddef.h)
instead of `uint64_t`.
And indeed, using `ptrdiff_t` fixes the warning. But as Stefan
Reinauer commented in [2], `intptr_t` is more appropriate as this
is just a pointer and no pointer difference.
So `intptr_t` is taken, which fixes these issues warned about too.
These warnings were introduced in commit »inteltool: Add support for
dumping AMB registers« (4b7b320f) [3].
[1] http://review.coreboot.org/#/c/2996/1//COMMIT_MSG
[2] http://review.coreboot.org/#/c/3002/1/util/inteltool/amb.c
[3] http://review.coreboot.org/525
Change-Id: I2ea1a31dc1e3db129e767d6a9e0433fd75a77d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3002
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry,
I have added __attribute__((always_inline)) for these.
Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This was there since the beginning
commit d24d6993b6
Author: arch import user (historical) <svn@openbios.org>
Date: Wed Jul 6 17:06:46 2005 +0000
Revision: linuxbios@linuxbios.org--devel/freebios--devel--2.0--patch-26
Creator: Hamish Guthrie <hamish@prodigi.ch>
Added AMD GX1 northbridge and cs5530 Southbridge
but blindly copied from Intel 440 BX and is not used anywhere.
Thanks to Idwer Vollering for spotting this.
Change-Id: I38b3d3feb25966c3aa382994d323e59c3f3c9e6c
Reported-by: Idwer Vollering
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3020
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
src/southbridge/intel/lynxpoint/pmutil.c was committed with two
things that needed fixing.
Change-Id: Ib83343a75840aa29847b607b0275971eb8140f12
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3003
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Commit 5d741567 added a prototype to broadcom.c to fix a warning. This part
is fine.
It also changed mainboard.c to #include broadcom.c. But broadcom.c is
already in Makefile.inc, now building will fail because the linker gets
broadcom_init() twice.
Undo the change to mainboard.c but keep the change to broadcom.c.
Change-Id: Ieccc098f477ffacccf4174056998034a220a9744
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3012
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
If ROM caching is selected the sandybridge chipset code will
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I3a57ba8753678146527ebf9547f5fbbd4f441f43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If ROM caching is selected the haswell CPU initialization code
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I75424bb75174bfeca001468c3272e6375e925122
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MP code on haswell was mirroring the BSPs MTRRs. In addition it
was cleaning up the ROM cache so that the MTRR register values were
the same once the OS was booted. Since the hyperthread sibling of
the BSP was going through this path the ROM cache was getting torn
down once the hyperthread was brought up.
That said, there was no differnce in observed boot time keeping the
ROM cache enabled.
Change-Id: I2a59988fcfeea9291202c961636ea761c2538837
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3008
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The haswell code was using the old assumption of which MTRR
was used for the ROM cache. Now that there is an API for doing
this use it as the old assumption is no longer valid.
Change-Id: I59ef897becfc9834d36d28840da6dc4f1145b0c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3007
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Adding a pxe rom manually is inconvenient.
With this patch, PXE ROM can be added automatically by selecting PXE_ROM in Kconfig.
I have tested this patch on AMD Parmer and Thatcher with iPXE.
iPXE would be a boot device in Seabios when pressing F12.
iPXE works well with coreboot and Seabios.
Change-Id: I2c4fc73fd9ae6c979f0af2290d410935f600e2c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3013
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that the ASRock E350M1 builds without any warnings, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: Idfecfb1434158969334a4b37972b5fc6fd76e72a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3014
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
When buidling inteltool with GCC, the following warning is printed.
$ make
[…]
gcc -O2 -g -Wall -W -c -o memory.o memory.c
memory.c: In function ‘print_mchbar’:
memory.c:287:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
[…]
This was introduced in commit »inteltool: Add support for H65 Express
chipset« (c7fc4422) [1].
Address this warning, by using `%llx` instead of `%lx`.
[1] http://review.coreboot.org/1258
Change-Id: I4f714edce7e8b405e1a7a417d02fa498322c88a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2994
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The help text says --machine, but the code
actually checked for --arch. Fix it!
Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building the ASRock E350M1, the following warnings are shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/buildOpts.romstage.o
In file included from src/mainboard/asrock/e350m1/buildOpts.c:294:0:
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:6: warning: "DDR1333_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:40: warning: "DDR1866_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:5: warning: "TIMING_MODE_AUTO" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:31: warning: "TIMING_MODE_SPECIFIC" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:5: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:33: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:5: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:28: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
[…]
Adding the corresponding defines as done for AMD Persimmon in
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
addresses the warnings.
Change-Id: Id311b2dacdba5f2e6b4d834e43db0310213a35f9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2962
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds configuration of SerialIO devices in the Lynxpoint-LP
chipset. This includes DMA, I2C, SPI, UART, and SDIO controllers.
There is assorted magic setup necessary for the devices and
while it is similar for each device there are subtle differences
in some register settings.
These devices must be put into "ACPI Mode" in order to take
advantage of S0ix. When in ACPI mode the allocated PCI BARs
must be passed to ACPI so it can be relayed to the OS. When
the devices are in ACPI mode BAR0+BAR1 is saved into ACPI NVS
and then updated and returned when the OS calls _CRS.
Note that is is not entirely complete yet. We need to update
the IASL compiler in our build environment to support ACPI 5.0
in order to be able to pass the FixedDMA entries to the kernel.
There are also no ACPI methods defined yet to do D0->D3->D0
transitions for actually entering/exiting S0ix states.
This is hard to test right now because our kernel does not support
any of these devices in ACPI mode. I was able to build and test
the upstream bleeding-edge branch of the linux-pm git tree. With
that tree I was able to enumerate and load the driver for the
DesignWare I2C driver and attempt to probe the I2C bus -- although
there are no devices attatched.
I am also able to see the resources from ACPI in /proc/iomem get
reserved properly in the kernel.
Change-Id: Ie311addd6a25f3b7edf3388fe68c1cd691a0a500
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2971
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables all of the SerialIO devices and sets the flag
to put them in ACPI mode.
Change-Id: I7436c47d26028e95bbefafc320854c7cc34a4d44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2972
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This bit offset is incorrect and should only be set based
on another bit in a different register.
Change-Id: I6037534236e3a4a5d15e15011ed9b5040b435eaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2973
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I did not check what was once after the 'and'.
Change-Id: I9f3f725bec281a94abdb2eeb692a96fecdebcc0c
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/2999
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The TPM code wasn't previously honoring MOCK_TPM=1. Because of this,
boards with TPMs that didn't handle S3 resume properly would cause a
hard reset. Allow one to build with MOCK_TPM=1 on the command line so
that S3 can still work.
Change-Id: I9adf06647de285c0b0a3203d8897be90d7783a1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2976
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The new enable_pm1() function was doing 2 things wrong:
1. It was doing a RMW of the pm1 register. This means we were
keeping around the enables from the OS during S3 resume. This
is bad in the face of the RTC alarm waking us up because it would
cause an infinite stream of SMIs.
2. The register size of PM1_EN is 16-bits. However, the previous
implementation was accessing it as a 32-bit register.
The PM1 enables should only be set to what we expect to handle in the
firmware before the OS changes to ACPI mode.
Change-Id: Ib1d3caf6c84a1670d9456ed159420c6cb64f555e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2978
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Building libpayload with the PDCurses backend the following warning
is shown.
/src/coreboot/payloads/libpayload(master) $ make clean
/src/coreboot/payloads/libpayload(master) $ make
[…]
CC curses/pdcurses-backend/pdcscrn.libcurses.o
curses/pdcurses-backend/pdcscrn.c: In function 'PDC_scr_open':
curses/pdcurses-backend/pdcscrn.c:75:5: warning: "CONFIG_SPEAKER" is not defined [-Wundef]
[…]
The GCC documentation states [1]
In some contexts this shortcut is undesirable. The -Wundef option
causes GCC to warn whenever it encounters an identifier which is
not a macro in an ‘#if’.
and therefore use `#ifdef` [2] to silence this warning. No functional
change is done, as `CONFIG_SPEAKER` is assigned the value `Y` when
defined.
There was some discussion going on the list [3], but my points in there
turned out to be incorrect.
[1] http://gcc.gnu.org/onlinedocs/cpp/If.html
[2] http://gcc.gnu.org/onlinedocs/cpp/Ifdef.html
[3] http://www.coreboot.org/pipermail/coreboot/2013-March/075561.html
Change-Id: I8e9c9b5d01985b21ad05018986d614cf9bf2b439
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2934
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Allow to override the variables `CC`, `INSTALL`, `PREFIX`,
`CFLAGS` and `LDFLAGS`. Though append `-lpci -lz` to `LDFLAGS`.
This way for example a different compiler can easily be used.
CC=clang make
As a side note, Clang in contrast to GCC does *not* issue the
following warnings.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
These are only shown under 32-bit and not 64-bit
$ uname -m
i686
and are going to be fixed in a separate patch.
Change-Id: Id75dea081ecb35390f283520a7e5dce520f4c98d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2996
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Put the ASL snippet for inclusion in the DSDT under the `acpi/`
folder as it is done for the other Super I/O devices.
$ find src/superio/ -name *asl
src/superio/ite/it8772f/acpi/superio.asl
src/superio/smsc/mec1308/acpi/superio.asl
src/superio/smsc/sio1007/acpi/superio.asl
src/superio/winbond/w83627hf/devtree.asl
As there are no users of this file yet, no other adaptations need
to be made.
Change-Id: Id10cd8897592b780c9fd3bd6b45ada4cf1fcf33e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2937
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c:64:12: warning: unused variable 'dev' [-Wunused-variable]
[…]
Removing the variable `dev` addresses the warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I83f4630cb6ab1e4c95d04b4e8423850ed1858e45
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c: In function 'smp_write_config_table':
src/mainboard/asrock/e350m1/mptable.c:58:3: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I7912571fa57f6512b10fc9b5845427fcb6eb50c0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mainboard.ramstage.o
src/mainboard/asrock/e350m1/mainboard.c: In function 'mainboard_enable':
src/mainboard/asrock/e350m1/mainboard.c:63:2: warning: implicit declaration of function 'pm_iowrite' [-Wimplicit-function-declaration]
[…]
This warning was introduced by moving the initialization of the
ASF registers using `pm_iowrite` to `mainboard.c` in
commit db6c5bfd8b
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Thu Mar 21 22:21:28 2013 +0100
Asrock E350M1: Use SPD read code from F14 wrapper
Reviewed-on: http://review.coreboot.org/2875
and is fixed by including `southbridge/amd/cimx/cimx_util.h`
declaring `pm_iowrite`.
Note, that the other AMD SB800 based boards seem to use the
header file `southbridge/amd/sb800/sb800.h`, so no warning is shown
for those. But since the CIMx SB800 code is used, the routines
from the CIMx directory are more appropriate to declare these functions.
So delete the commented out include line for this header too.
Change-Id: I179aad5157c5a91294339a3e7b6c4c1715c6f099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the power management register definitions for Intel's Cougar
Point and Panther Point platform controller hubs (PCH). The definitions
are actually a subset of the older ICH10R registers: I've added just
those that are mentioned in the public specifications in [1] and [2].
I've tested dumping with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: Ia6945fe96cd96b568ed5191e91dbba5556e1ee95
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stefan Reinauer