The _OSC method is used to tell the OS what capabilities it can
take control over from the firmware. This method is described
in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4
inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and
returns a Capabilites Buffer the same size as the input Buffer.
This Buffer is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control Dword.
The OS will request control of certain capabilities and the
firmware must grant or deny control of those features. We do not
want to have control over anything so let the OS control as much
as it can.
The _OSC method is required for PCIe devices. During Linux boot,
an error is logged to dmesg if _OSC is not found.
Change-Id: Icf6e7a82284d03d23fd30ee7b7db17754e988c9a
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3823
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the AMD FCH ACPI code.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'
By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`. PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge. However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.
Change-Id: Ib2d36f69a26b715798ef1ea17deb0905fa0cad87
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3822
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Split the Family16 (Kabini) DSDT file into logical regions.
Olive Hill is the only mainboard and Kabini is the only NB/CPU
currently using Family16 AGESA code.
Change-Id: I9ef9a7245d14c59f664fc768d0ffa92ef5db7484
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3821
Tested-by: build bot (Jenkins)
Hook this up into the DMP Vortex86EX. Before under Windows XP
the microphone did not work. With the new logic it does. Now
line-in,line-out and microphone all work.
The verb data table is generated by Realtek.
Change-Id: I1bcef898a15547c86c12c4b52ce0069d13e23c84
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3855
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
These Kconfig entries were forgotten from the commit
that re-enabled usbdebug for these southbridges.
Change-Id: Ia17f1dd3340408da7c033c2c949404d2636bed44
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3849
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I58c4b021ac87a035ac2ec2b6b110b75e6d263ab4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3810
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Rearranged the F2A85-M DSDT file to match the functionality found
on Parmer. As with the Parmer implementation, the F2A85-M dsdt.asl
file in the mainboard directory contains only #include references to
the appropriate files.
As with Parmer, some include files have no content but are left as a
template for other platforms and as placeholders for completing the
ACPI implementation for F2A85-M.
Change-Id: Ic72cb6004538ca9d9f79826b9b3c8d6aeb25017c
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/3805
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Support code for sb700 and sb800 existed already, but Kconfig and
compile-time issues prevented from enabling USBDEBUG for boards
with the affected AMD southbridges.
Change-Id: I49e955fcc6e54927320b9dc7f62ea00c55c3cedf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3439
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
With USBDEBUG selected, the file is built for both romstage and
ramstage. For the ramstage build, we need to explicitly use the
simple PCI config operations without devicetree.
Change-Id: I2de8d9c77bb458ba797c3aac9e2cd0d653e06684
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3437
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This patch sets a bit in the Yangtze southbridge to enable
the extra protocol necessary to handle port multiplier chips.
This has been turned on during most of Kabini development
without any notable impact. Olive Hill has an optional daughter
board that incorporates Silicon Image Steel Vines chips. This
change has been tested with and without the daughter board. This
change can be regression tested using any Hudson-based motherboard,
although it has no impact on boards with discreet Hudson/Bolton
southbridges.
This was tested for impact on SATA performance in the absence of
a port multiplier using the IOZone benchmarks within the Phoronix
Test Suite. A SATA 3 hard drive (6.0 Gbps) and an SSD were
connected to the ports on Olive Hill without using the port
multiplier card. The test results contained more run-to-run
variation within the same configuration than was seen in the
aggregate results comparing the interface with and without the
port multiplier protocol additions. In other words, the test
had less accuracy than the impact caused by turning on port
multiplier support.
Change-Id: Ie87873b093f3e2a6a5c83b96ccb6c898d3e25f72
Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3808
Tested-by: build bot (Jenkins)
Yangtze uses Hudson AGESA wrapper code but has some changes.
The changes are necessary and have no effects on Hudson.
Change-Id: Iada90d34fdc2025bd14f566488ee12810a28ac0d
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3783
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I71923790aa03e51db01ae3a4745e1c44556d281f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3812
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The tests for __PRE_RAM__ or __SMM__ were repeatedly used
for detection if dev->ops in the devicetree are not available
and simple device model functions need be used.
If a source file build for ramstage had __PRE_RAM__ inserted
at the beginning, the struct device would no longer match the
allocation the object had taken. This problem is fixed by
replacing such cases with explicit __SIMPLE_DEVICE__.
Change-Id: Ib74c9b2d8753e6e37e1a23fcfaa2f3657790d4c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3555
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Directory intel/common must be conditionally added in the list
of source directories, as the parent directory southbridge/intel
is unconditionally added even for boards without such device.
Change-Id: I7088bc6db9f56909ffa996aa7eff76cd72e177eb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3827
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Split the Parmer, Family 15tn, and Hudson DSDT into groups. This splits
the DSDT table into includable ASL files which carry details specific
to the Family 15tn APU, the Parmer platform, and the Hudson FCH. The
dsdt.asl file in the mainboard directory contains only #include
references to the appropriate files.
Initially, this split was done by moving each piece of functionality
into its own file (e.g. IRQ routing and mapping, processor tree, sleep
states and sleep methods, etc.) and those pieces were #included in
dsdt.asl to ensure an exact match (via acpidump/acpixtract/iasl -d)
with the extant version of the table. Once the new tables were found
to exactly match the existing tables, the pieces were rearranged into
reasonable groups (e.g. fch.asl, northbridge.asl, pci_int.asl, etc.).
Some include files have no content but are left as a template for
other platforms and as placeholders for completing the ACPI
implementation for Parmer (e.g. thermal.asl, superio.asl, ide.asl,
sata.asl, etc.).
Change-Id: I098b0c5ca27629da9bc1cff1e6ba9fa6703e2710
Signed-off-by: Steve Goodrich <steve.goodrich@se-eng.com>
Reviewed-on: http://review.coreboot.org/3629
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Routes IRQs for USB device, SPI1, MOTOR, HD audio, CAN bus.
Change-Id: I995a5c6d3ed6a7dca4f0d21545c928132ccbbc21
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3725
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Without that fix, and with CONFIG_SMM_TSEG, we have:
src/southbridge/intel/i82801gx/smihandler.c: In function 'southbridge_smi_sleep':
src/southbridge/intel/i82801gx/smihandler.c:340:3: error: implicit declaration of function 'smi_release_lock' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make: *** [build/southbridge/intel/i82801gx/smihandler.smm.o] Error 1
The fix is modelled after src/cpu/x86/smm/smihandler.c which
ifdefs smi_release_lock().
Change-Id: Icdc6d039b34a1d95d0e607419bba2484d21abc5e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3281
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This mistake was spoted by comparison with the
src/southbridge/intel/bd82x6x/smihandler.c file.
Change-Id: I1516f0131d524bd7d001e6780e9a45402d1814d1
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add an option to mark all SPI regions write protected on each S3 resume.
We were used to lock the SPI interface in the payload which isn't run on
the resume path. So we have to do it here.
For the write protection to be effective, all write opcodes in the
opmenu have to be marked correctly (as write operations) and the whole
SPI interface has to be locked. Both is already done.
Change-Id: I5c268ae8850642f5e82f18c28c71cf1ae248dbff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3594
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All the additional work that needs to be done in EHCI BAR relocation
is independent of the hardware platform and was functionally identical
in all the copies removed.
When USBDEBUG is not selected, PCI EHCI controllers use standard
pci_dev_read_resources() call.
With USBDEBUG selected, PCI EHCI controller's device_operations
.read_resources is replaced with pci_ehci_read_resources() call,
which in turn will replace the device_operations .set_resources call.
The replacement for .set_resources reconfigures usbdebug driver side,
and calls the original .set_resources to configure hardware side.
Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3412
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch is based on 'AMD S3: Program the flash in a bigger data packet'[1]
Some AMD south bridge can write bigger data when saving S3 info.
In this patch, I use config 'AMD_SB_SPI_TX_LEN' to contral data size.
AMD_SB_SPI_TX_LEN is defined in 'src/southbridge/amd/Kconfig'
and then can be overridden in the Kconfig for specific
southbridges that support larger size.
I have tested on AMD Parmer and Thatcher. We will release a new board
whose south bridge can transfer more than 4 bytes each time.
[1] http://review.coreboot.org/#/c/2306/
Change-Id: Id984955d46eae487e39d45979f1a90054aa9f54b
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3413
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change inserts a type cast to eliminate a compiler warning.
Change-Id: If223f61f1565caeadb1b7e0762975b1b2412eda5
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3541
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The xHCI controller's MMIO space has a length of 64KiB not 4KiB.
Therefore, setting the xHCI BAR to 0xe8001000 worked the same like
setting it to 0xe8000000, as bit12 is reserved and ignored. This again
interfered with the MMIO space of the first EHCI controller and broke
S3 resume on Ivy Bridge.
AFAIK, the MRC ignores the setting of the xHCI BAR, anyway. So just drop
these lines.
Change-Id: I8af9c2ba34133f15636a9056fc8880b3b6ab95e0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3521
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Current build configuration always wants to include an Intel Management
Engine firmware (me.bin) on Sandy Bridge systems. However, we can have
a working coreboot without it, as long as the factory delivered ME
firmware is kept untouched in the flash ROM. So let the user decide if
a ME firmware will be included in the build.
Change-Id: I9a1cc29d4940ba22355eb9e653606e436f07e04c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3522
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On newer Intel systems, the flash ROM is shared between the host
processor (BIOS), it's Management Engine (ME) and an integrated ethernet
controller (GbE). The layout of the flash ROM (and other information) is
kept in the so called Intel Firmware Descriptor (IFD). If we only want
to build coreboot to update the BIOS section, all we need is the flash
layout.
This patch adds the option to specify the flash layout in the
mainboard's Kconfig, and thus, to build without the real IFD. However,
with such a build, one has to make sure that the IFD section on the
flash ROM won't be written over (nor any other section that hasn't been
included by coreboot). A patch to write selected sections of a flash ROM
with IFD has been sent to the flashrom mailing list [1].
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
Change-Id: Ia23e439a00a197fb54852263f8e206f16c3e8851
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3524
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LynxPoint LP has only EHCI controller #1.
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: I95c59fb9d5f09afd152872e9bc0418dc67e4aeb2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3472
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: Ib6f7cfac5acf3f8170508547d1584af90273e8c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3471
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Upgrade the ICH7 bootblock to store an initial timestamp like we do it
since Sandy Brigde. I've checked the datasheets for the used scratchpad
registers and grepped for their usage. I'm pretty sure that they aren't
used on any ICH7 based board (for anything before the usual S3-resume
indication).
Change-Id: I28a9b90d3e6f6401a8114ecd240554a5dddc0eb5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
All 3 boards with AGESA_HUDSON had HAVE_HARD_RESET with the reset.c
file already placed under southbridge/.
All 15 boards with CIMX_SBx00 had HAVE_HARD_RESET with functionally
identical reset.c file under mainboard/. Move those files under
respective southbridge/.
Change-Id: Icfda51527ee62e578067a7fc9dcf60bc9860b269
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3486
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
To have USB 3.0 support the XHCI controller needs to be enabled
and the xhci.bin firmware needs to be added to CBFS.
Change-Id: I0b641b30b67163b7dc73ee7ae67efe678e11c000
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3464
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
They were hard-coded to be copied from 3rdparty/ which isn't always
the right choice.
Since the defaults stay the same, this should be compatible.
Change-Id: If2173bef86ad1fcf2335e13472ea8ca41eb41f3d
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3453
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The original lines had contradicting comment and code.
This change follows the code and sets MASTER bit too.
Change-Id: Id2886bfc107612530f0e9747e5d49a9740fb8532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3466
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This patch provides the correct SD controller timings for
the Family16 device. It also will remove the SD controller
from PCI space when device 0:14.7 is set to off in devicetree.
This was tested on a AMD Parmer board and a AMD G-series SOC
reference board. The settings were found in the AMD
Hudson2 RRG and family16 BKGD.
Change-Id: I6d7e7997ddc39802ab75dc8a211ed29f028c0471
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3348
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In case with EARLY_CONSOLE, this printk is called before any other
console is configured to transmit data. This outputs garbage on
CONSOLE_SERIAL as baudrate is not yet programmed.
For case without EARLY_CONSOLE, the order in which different console
drivers initialize is obscure. Might sometimes work properly.
Change-Id: I3792161e0a6dc17e17262048cc9136044dd69dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3384
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Setting IRQ delivery to FSB got lost in the rebase process
for commit e6143531.
I captured following error on dmesg and this patch fixes it for
i82801dx.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... works.
Change-Id: I0768976cc6b0deab213ad9bd4771e0f278de634c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3371
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Mapping is as follows: bit 15 corresponds to GPIO15 ... bit 0 corresponds to
GPIO0.
Change-Id: I661ce56d9373887270ba3c0518892fbbe6d9de7c
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3436
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently in Intel BD82x6x southbridge’s `Makefile.inc` the
file `usb_debug.c` is added twice to the build.
This was introduced in
commit 4063ede3fb
Author: Ronald G. Minnich <rminnich@google.com>
Date: Mon Feb 4 20:31:51 2013 -0800
bd82x6x: Fix compiling with USB debug port support
Reviewed-on: http://review.coreboot.org/2784
but was unneeded because it had been already added in
the following commit.
commit 4141993536
Author: Sven Schnelle <svens@stackframe.org>
Date: Sat Jul 28 08:52:44 2012 +0200
bd82x6x: Fix CONFIG_USBDEBUG
Reviewed-on: http://review.coreboot.org/1376
Therefore basically revert that hunk.
There is no policy on how to order these additions, so leave
it to a possible separate commit, unifying this.
Kyösti Mälkki suspects that these additions were meant for
the Intel Lynx Point [1].
[1] http://review.coreboot.org/#/c/3424/
Change-Id: Iaa8de6fcc0d6f3a0a92a28fcb603d7777aa8b24c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3425
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix obvious mistake in cycle that displays GPI status
I hope i found all duplicates of it.
Change-Id: Ic21ff3ecab85953463e5c23daf808dd5edc82ff8
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3435
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Mike Loptien