Commit Graph

9017 Commits

Author SHA1 Message Date
Hung-Te Lin 6bfbb33a64 ec/google: Support Google's Chrome EC on I2C interface.
Google's Chrome EC can be installed on LPC or I2C bus, using different command
protocol.  This commit adds I2C support for devices like Google/Snow.

Note: I2C interface cannot be automatically probed so the bus and chip number
must be explicitly set.

Verified by booting Google/Snow, with following console output:
  Google Chrome EC: Hello got back 11223344 status (0)
  Google Chrome EC: version:
     ro: snow_v1.3.108-30f8374
     rw: snow_v1.3.128-e35f60e
    running image: 1

Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3074
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16 00:32:49 +02:00
Paul Menzel 07e0f1bf1a AMD AGESA: Fix argument list for `PCIE_DDI_DATA_INITIALIZER` in comments
When looking into possible reasons for a proposed revert [1], I noticed
that the comments use four arguments for `PCIE_DDI_DATA_INITIALIZER`,
but the actual definition only uses three.

    $ git grep -A1 PCIE_DDI_DATA_INITIALIZER # manually squeeze whitespace in output
    […]
    --
    src/vendorcode/amd/agesa/f10/AGESA.h:#define  PCIE_DDI_DATA_INITIALIZER(mConnectorType, mAuxIndex, mHpdIndex ) \
    src/vendorcode/amd/agesa/f10/AGESA.h-{mConnectorType, mAuxIndex, mHpdIndex}
    --
    src/vendorcode/amd/agesa/f10/AGESA.h:   *      PCIE_DDI_DATA_INITIALIZER (ConnectorType
    src/vendorcode/amd/agesa/f10/AGESA.h-   *    },
    --
    src/vendorcode/amd/agesa/f10/AGESA.h:   *      PCIE_DDI_DATA_INITIALIZER (ConnectorType
    src/vendorcode/amd/agesa/f10/AGESA.h-   *    }
    --
    […]

So remove the fourth argument in the comments. Luckily the compiler,
at least gcc, warns about a wrong number of arguments, and therefore
no incorrect code resulted from the wrong documentation.

[1] http://review.coreboot.org/#/c/3077/

Change-Id: I3e5a02c66a23af1eb2d86be8dbc7aaa3e5cea05e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3080
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16 00:14:12 +02:00
Mike Loptien 8764b0e1c0 Fam14 DSDT: Also return for unrecognized UUID in _OSC
Fixing warnings introduced by the following patches:
http://review.coreboot.org/#/c/2684/
http://review.coreboot.org/#/c/2739/
http://review.coreboot.org/#/c/2714/

These patches were meant to fix the dmesg warning about
the OSC method not granting control appropriately.  These
patches then introduced warnings during the coreboot build
process which were missed during the patch submission
process.  These warnings are below:

	Intel ACPI Component Architecture
	ASL Optimizing Compiler version 20100528 [Oct 15 2010]
	Copyright (c) 2000 - 2010 Intel Corporation
	Supports ACPI Specification Revision 4.0a

		dsdt.ramstage.asl  1143:    Method(_OSC,4)
		Warning  1088 -                       ^ Not all control paths return a value (_OSC)

		dsdt.ramstage.asl  1143:    Method(_OSC,4)
		Warning  1081 -                       ^ Reserved method must return a value (Buffer required for _OSC)

	ASL Input:  dsdt.ramstage.asl - 1724 lines, 34917 bytes, 889 keywords
	AML Output: dsdt.ramstage.aml - 10470 bytes, 409 named objects, 480 executable opcodes

	Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 494 Optimizations

This patch gives the following compilation status:

	Intel ACPI Component Architecture
	ASL Optimizing Compiler version 20100528 [Oct  1 2012]
	Copyright (c) 2000 - 2010 Intel Corporation
	Supports ACPI Specification Revision 4.0a

	ASL Input:  dsdt.ramstage.asl - 1732 lines, 33295 bytes, 941 keywords
	AML Output: dsdt.ramstage.aml - 10152 bytes, 406 named objects, 535 executable opcodes

	Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 432 Optimizations

The fix is simply adding an Else statement to the If which checks
for the proper UUID.  This way, all outcomes will return a full
control package.  This patch has no effect on the dmesg output.

Change-Id: I8fa246400310b26679ffa3aa278069d2e9507160
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3052
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15 23:42:34 +02:00
Paul Menzel 17c05f23e2 inteltool: pcie.c: Use `0xffULL` instead of `0xff` to avoid shift overflow
When building inteltool with Clang, it warns about the following.

    $ 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
    $ CC=clang make
    […]
    clang -O2 -g -Wall -W   -c -o pcie.o pcie.c
    pcie.c:297:40: warning: signed shift result (0xFF0000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
                    pciexbar_phys = pciexbar_reg & (0xff << 28);
                                                    ~~~~ ^  ~~
    pcie.c:301:41: warning: signed shift result (0xFF8000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
                    pciexbar_phys = pciexbar_reg & (0x1ff << 27);
                                                    ~~~~~ ^  ~~
    pcie.c:305:41: warning: signed shift result (0xFFC000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
                    pciexbar_phys = pciexbar_reg & (0x3ff << 26);
                                                    ~~~~~ ^  ~~
    3 warnings generated.
    […]

Specifying the length by using the suffix `0xffULL` fixes these issues
as now enough bits are available.

These issues were introduced in commit 1162f25a [1].

    commit 1162f25a49
    Author: Stefan Reinauer <stepan@coresystems.de>
    Date:   Thu Dec 4 15:18:20 2008 +0000

        Patch to util/inteltool:
        * PMBASE dumping now knows the registers.
        * Add support for i965, i975, ICH8M
        * Add support for Darwin OS using DirectIO

[1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1162f25a49e8f39822123d664cda10fef466b351

Change-Id: I7b9a15b04ef3bcae64e06266667597d0f9f07b79
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3015
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15 19:03:19 +02:00
Kyösti Mälkki 18ac0d52b7 Drop add_mainboard_resources and HAVE_MAINBOARD_RESOURCES again
These are not defined since commit »Drop HAVE_MAINBOARD_RESOURCES«
(1c5071d1) [1] but were unfortunately introduced again in new ports.

[1] http://review.coreboot.org/1414

Change-Id: I5eb61628141aefd08779615702d51ca155fa632a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2707
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-15 07:29:13 +02:00
Paul Menzel c3fc1e05a6 cbmem: Makefile: Allow to override `CC` variable
Now users can use a different compiler from GCC like Clang by for example
doing `CC=clang make`.

Change-Id: I664a36df79f7496a56d89bdb61948b2eda33a6b4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3082
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15 07:00:23 +02:00
Paul Menzel 15a1fd1db9 inteltool: Use portable type `uint64_t` instead of `u64`
In [1] Idwer Vollering noted, that the type `u64` is not portable so
on his FreeBSD system, the following warning is shown.

    $ clang -O2 -Wall -W -I/usr/local/include   -c -o amb.o amb.c
    amb.c:441:22: error: use of undeclared identifier 'u64'
                    ambconfig_phys = ((u64)pci_read_long(dev16, 0x4c) << 32) |

The type `uint64_t` seems to be defined also on FreeBSD, so using this
fixes the warning.

Note, this warning is not reproducable with Debian Sid/unstable for
example. I have no idea why though.

[1] http://review.coreboot.org/#/c/3015/

Change-Id: Ic22f4371114b68ae8221d84a01fef6888d43f365
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3086
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14 23:00:35 +02:00
Paul Menzel 0b31286796 AMD CIMx sb800/SATA.c, sb900/Sata.c: Fix R*AI*D typo in comments
Spell RAID correctly in comments. Found with the following command.

    $ git grep -i riad

Change-Id: I68e8476d885a88df589d25f88cc158d71eb04e07
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3081
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14 19:28:50 +02:00
Paul Menzel cb891de07f cbmem: parse_cbtable: Use length modifier `ll` `u64` argument
Currently on a 32-bit system cbmem fails to build due to `-Werror`
and the following warning.

    $ make
    cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86  -c -o cbmem.o cbmem.c
    […]
    cbmem.c: In function ‘parse_cbtable’:
    cbmem.c:135:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64’ [-Werror=format]
    cc1: all warnings being treated as errors
    […]

Using the length modifier `ll` instead of `l` gets rid of this
warning.

Change-Id: Ib2656e27594c7aaa687aa84bf07042933f840e46
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3084
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14 02:06:21 +02:00
Denis 'GNUtoo' Carikli b8eb0a802f link/graphics: Remove the inclusion of an AMD header.
link(google chromebook pixel) is an intel machine.

Change-Id: I9d40f1e945021d8e190879477cd12be7d0262733
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3085
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14 02:05:35 +02:00
David Hendricks cd4c8c1e0e exynos5/snow: remove wait_ms arg from dp_controller_init()
This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.

(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).

Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-13 05:12:18 +02:00
Ronald G. Minnich c0b972f60d Exynos5250: add a microsecond timer
Add a microsecond timer, its declaration, the function to start it,
and its usage.  To start it, one calls timer_start().  From that point
on, one can call timer_us() to find microseconds since the timer was
started.

We show its use in the bootblock. You want it started very early.

Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.

We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.

Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
2013-04-13 00:47:27 +02:00
Paul Menzel 2c8f81b57b cbfstool: cbfs-mkstage.c: Free `buffer` on error path
Cppcheck warns about a memory leak, present since adding romtool,
which was renamed to cbfstool, in commit 5d01ec0f.

    $ cppcheck --version
    Cppcheck 1.59
    […]
    [cbfs-mkstage.c:170]: (error) Memory leak: buffer
    […]

Indeed the memory pointed to by `buffer` is not freed on the error path,
so add `free(buffer)` to fix this.

Change-Id: I6cbf82479027747c800c5fe847f20b779e261ef4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3069
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-12 20:22:39 +02:00
Idwer Vollering e76d8d7ced acpica: update URL
The URL to acpica-unix-20121114 has changed, update the URL.

Change-Id: I1c8c228094f19455af3682f36f1990586fe3934c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3070
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-12 20:15:51 +02:00
Nico Huber 8ecec215be Revert "siemens/sitemp_g1p1: Make ACPI report the right mmconf region"
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5:

    commit 1fde22c54c
    Author: Patrick Georgi <patrick.georgi@secunet.com>
    Date:   Tue Apr 9 15:41:23 2013 +0200

        siemens/sitemp_g1p1: Make ACPI report the right mmconf region

        ACPI reported the entire space between top-of-memory and some
        (relatively) arbitrary limit as useful for MMIO. Unfortunately
        the HyperTransport configuration disagreed. Make them match up.

        Other boards are not affected since they don't report any region
        for that purpose at all (it seems).

        Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
        Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
        Reviewed-on: http://review.coreboot.org/3047
        Tested-by: build bot (Jenkins)
        Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>

It sneaked in without it's dependencies and, therefore, broke the build for
all amdk8 targets. Paul Menzel already commented on the issue in [1]. It
also doesn't look like the dependencies would be pulled soon [2].

[1] http://review.coreboot.org/#/c/3047/
[2] http://review.coreboot.org/#/c/2662/

Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3063
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-04-12 11:48:15 +02:00
Siyuan Wang 7f23aeb05d AMD Thatcher: Fix PCIE link issues
1). Thatcher PCIE x8 slot is reverse order.
Although the PCIE slot is x16, it actually uses 8 lanes(15:8).
Because the PCIE slot is configured by PortList[0], fix this item can enable the slot.
A x1 PCIE network adapter works well in this slot.

2). Fix DdiList to detect DP monitor or HDMI monitor.
GPIO50 can be used to detect DP0/HDMI0 monitor.
If GPIO50 is 1, it is DP monitor. If GPIO50 is 0, it is HDMI monitor.
GPIO51 can be used to detect DP1/HDMI1 in the same way.

3). Disable unused PCIE port and clean up code in PlatformGnbPcie.c and devicetree.cb.
PCIE port 3 and 7 are not used in Thatcher.

Change-Id: I8524b6fc1b6cdc03ba92e7191186bfb0986767c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-12 06:01:17 +02:00
Hung-Te Lin a904f9ef69 ec/google: Isolate EC bus protocol implementation.
The Chrome EC can be connected by different types of bus like LPC / I2C / SPI,
and the current implementation is only for LPC.

To support other types, we must first isolate the LPC protocol stuff and add
configuration variable (EC_GOOGLE_CHROMEEC_LPC) to specify bus type.

Verified by building google/link (with chromeec) configuration successfully.

Change-Id: Ib2920d8d935bcc77a5394e818f69e9265e26e8a0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3068
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-12 04:57:39 +02:00
Steven Sherk d9de6c4f0e Add new superio device
- Added in new support for Nuvoton NCT5104D LPC device.

Change-Id: I0af8c5e3e46fdd0a549475b30917897ae9e144a7
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: http://review.coreboot.org/3072
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-12 00:37:34 +02:00
Paul Menzel 6a1210901d AMD RS780, SR5650: PcieTrainPort: Fix typo *i*gnoring in comment
Reading the paste of code in a message to the mailing list [1],
a typo was spotted and found in one more place.

    $ git grep egnoring
    src/southbridge/amd/rs780/cmn.c:                         * egnoring the reversal case
    src/southbridge/amd/sr5650/sr5650.c:                     * egnoring the reversal case

These typos are there since when the code was committed and are
now corrected.

[1] http://www.coreboot.org/pipermail/coreboot/2013-April/075644.html

Change-Id: I55c65f71e4834f209b60d678f0d44bc2f4217099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3062
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-11 22:04:20 +02:00
Mike Loptien 573a1d6fa8 Persimmon/Fam14/SB800 DSDT: Split into common areas
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory.  Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future.  I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time.  Removing
it until it is decided that it is actually necessary.

This change was verified in three different ways:
	1. Visual comparison of the compiled DSDT pulled from the
	Persimmon after booting into Linux using the ACPI tools
	acpidump, acpixtract, and iasl.  The comparison was done
	between the DSDT before and after doing the split work.

	This test is somewhat difficult considering the expanse
	of the changes.  Blocks of code have been moved, and
	others changed.

	2. Linux logs were dumped before and after the DSDT split.
	Logs dumped and compared include dmesg and lspci -tv.
	Neither log changed significantly between the two compare
	points.

	3. The test suite FWTS was run on the Coreboot build both
	before and after doing the DSDT split with the command
	'sudo fwts -b -P -u'.  The flag -b specifies all batch jobs,
	-P specifies all power tests, and -u specifies utilities.
	Interactive jobs were not run as most of them consist of
	laptop checks.  Again, there were no significant changes
	between the two endpoints.

These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.

This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)

Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-11 21:48:27 +02:00
Paul Menzel 109a710743 libpayload: storage.c: Fix typo in st*orage in comment
Reading commit »libpayload: New AHCI, ATA and ATAPI drivers«
(1f6bd94f) [1], the spelling error was found and is now fixed.

[1] http://review.coreboot.org/1622

Change-Id: Id418bcb99c1a9a400a49fc04078e465bd0908074
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3071
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-11 18:09:20 +02:00
Gabe Black 1a5c9cd33b Snow: Set up the ChromeOS GPIOs as inputs during the ROM stage.
We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.

It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.

Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
2013-04-11 04:13:49 +02:00
Gabe Black fe3b024a44 Snow: Fix the recovery GPIO polarity, and lid GPIO polarity and number.
Change-Id: I34097f878291367b28962048190e11ccaacfc514
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3066
Tested-by: build bot (Jenkins)
2013-04-11 04:13:28 +02:00
Gabe Black 514f202939 ARM: Unmask aborts very early in the bootblock.
It's better to recognize aborts when they occur than to mask them to
discover them later without knowing where they actually came from.

Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3065
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2013-04-11 04:12:16 +02:00
Mike Loptien 8d80a3fb9f ASRock DSDT: Split the ASRock DSDT
This is the same split as was done on the Persimmon.

Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-11 00:53:17 +02:00
Ronald G. Minnich b48605da20 Exynos5250: Use new chip settings for the cpu
Properly use the chip settings when configuring the CPU,
at this point being purely graphics.

Change-Id: I9bc2d32c1037653837937b314e4041abc0024835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3054
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-11 00:11:51 +02:00
Patrick Georgi 1fde22c54c siemens/sitemp_g1p1: Make ACPI report the right mmconf region
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.

Other boards are not affected since they don't report any region
for that purpose at all (it seems).

Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10 17:40:49 +02:00
Ronald G. Minnich 7576f2515e GOOGLE/SNOW: add edp support to ramstage
Add basic edp support to the ramstage. Not working.

Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
2013-04-10 17:37:25 +02:00
David Hendricks 765ff76d8f [2/2] tps65090: re-factor for coreboot
This does basic re-factoring to fit the driver into coreboot.

Change-Id: Id5f8c12a73ec37ddd545d50b3e8e9b3012657db1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3061
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10 17:34:19 +02:00
David Hendricks 6e877ec63e [1/2] initial import of TI TPS65090
This imports TPS65090 PMIC from u-boot and adds/updates Makefiles
and Kconfig files. The follow-up patch will re-factor the code.

Change-Id: Ic9e43b9665ddf7f55feae8fa17fbf3d2d5f4756d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3060
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10 17:33:13 +02:00
Ronald G. Minnich 767edfc542 GOOGLE/SNOW: clean up the device tree
This is a simpler device tree that is also more correct,
and has graphics settings as well.

Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
2013-04-10 17:31:05 +02:00
Ronald G. Minnich 798f6649a9 exynos5-common: Enable fimd_bypass and minor cleanup
Basic cleanup, this code still does not work.

Change-Id: I84ed9f08fd04cd8eb74cd860e0775d8c602f42d6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3049
Tested-by: build bot (Jenkins)
2013-04-10 17:30:30 +02:00
David Hendricks 086b369dfc armv7: replace read/write macros with inlines
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.

This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.

Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
	setbits_le32(&regs->ch_cfg, SPI_CH_RST);
	clrbits_le32(&regs->ch_cfg, SPI_CH_RST);

In such cases the safe versions of readl() and writel() should be
used anyway.

Note: This also fixes two dubious casts as to avoid breaking
compilation.

Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10 00:04:57 +02:00
David Hendricks b959fbb87a exynos5: Re-factor I2C code
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.

- i2c_read() and i2c_write() functions updated to take bus number
  as an argument.

- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
  i2c_write(). If a chip needs special handling we should take care
  of it elsewhere, not in every low-level i2c driver.

- All the confusing bus config functions eliminated. No more
  i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
  is handled automatically when the caller does a transaction and
  specifies the desired bus number.

- i2c_probe() eliminated. We're not a command-line utility.

- Let the compiler place static variables automatically. We don't need
  any of this fancy manual data placement.

- Remove dead code while we're at it. This stuff was ported early on
  and much of it was left commented out in case we needed it. Some
  also includes nested macros which caused gcc to complain.

- Clean up #includes (no more common.h, woohoo!), replace debug() with
  printk().

Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10 00:01:02 +02:00
David Hendricks cfb73607be replace device/i2c.h with simpler version
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:

- We only need to expose i2c_read() and i2c_write() in our public API.
  Everything else is board/chip-dependent and should remain hidden
  away.

- i2c_read and i2c_write functions will take bus number as an arg
  and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
  error and end up cluttering the code since the user needs to save
  the old bus number, set the new one, do the read/write, and restore
  the old value (3 added steps to do a simple transaction).

- Stop setting default values for board-specific things like SPD
  and RTC bus numbers (as if we always have an SPD or RTC on I2C).

- Death to all the trivial inline wrappers. And in case there was any
  doubt, we really don't care about the MPC8xx. Though if we did then
  we would not pollute the public API with its idiosyncrasies.

Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09 23:59:34 +02:00
Jens Rottmann 4026b034f1 FrontRunner/Toucan-AF: boards will be renamed to fit ADLINK scheme
Originally developed by LiPPERT and after the acquisition marketed as
'LiPPERT by ADLINK', the plan is now to streamline both boards into the
ADLINK naming scheme.  But AFAIK a few have already been sold and as of
this writing the website still advertises the old names.  And in any case
the veteran LX products will continue to be sold by ADLINK under their
original names.

So create CONFIG_VENDOR_ADLINK, currently only telling users to look under
LiPPERT (however any future boards will be added here).

Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard
model selection show both names.

Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3046
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09 23:56:14 +02:00
Vladimir Serbinenko f4a0d019fa util/cbmem: Don't output trailing garbage for cbmemc
Current code outputs the whole cbmemc buffer even if only part of
it is really used. Fix it to output only the used part and notify
the user if the buffer was too small for the required data.

Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2991
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09 23:52:36 +02:00
Stefan Reinauer 33e83caff5 cbfstool: completely initialize input and output streams
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:

        commit aa3f7ba36e
        Author: Stefan Reinauer <reinauer@chromium.org>
        Date:   Thu Mar 28 16:51:45 2013 -0700

            cbfstool: Replace C++ code with C code

            Reviewed-on: http://review.coreboot.org/3010

In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.

Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08 21:36:37 +02:00
Stefan Reinauer bb2cc71480 Fix read_option invocation in uart8250mem.c
read_option was unified between ramstage and romstage a while ago.
However, it seems some invocations were not fixed accordingly.
This patch switches uart8250mem.c to use the new scheme.

Change-Id: I03cef4f6ee9188a6412c61d7ed34fbaff808a32b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3033
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08 21:36:01 +02:00
Stefan Reinauer 84463efb94 Fix compilation when coverage debugging is enabled
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>
2013-04-08 21:35:26 +02:00
Gabe Black 9e8af58263 libpayload: Handle multifunction bridge devices better.
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>
2013-04-08 20:27:46 +02:00
David Hendricks 6d0fe9cad0 armv7: specify condition code for msr instruction
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>
2013-04-08 18:31:08 +02:00
David Hendricks c7e5d79842 exynos5250: add missing address-of operator in UART driver
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>
2013-04-08 18:30:03 +02:00
Stefan Tauner 0c8b7d1ac2 inteltool: remove unused file descriptor variable and ifdefs
Change-Id: I6a119b1f362f481914377e8d14c713159f895130
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3030
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08 18:17:59 +02:00
David Hendricks db9eaf4cb2 snow/exynos5250: move board-specific power stuff to mainboard dir
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>
2013-04-08 18:16:06 +02:00
Ronald G. Minnich 161ccc76ea exynos5250: add a chip.h file for the display register settings
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)
2013-04-06 08:17:46 +02:00
Aaron Durbin 6ccb1abfd4 mtrr: add rom caching comment about hyperthreads
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>
2013-04-05 21:57:38 +02:00
Stefan Tauner 0dc775e894 inteltool: use inttypes for prints in memory.c
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>
2013-04-05 20:21:35 +02:00
Ronald G. Minnich ce801b55fa exynos5-common: get rid of displayport trial code
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>
2013-04-05 20:17:35 +02:00
Paul Menzel 5f3754e66d inteltool: cpu.c: Use conversion specifier `u` for unsigned integers
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>
2013-04-05 20:17:03 +02:00