the following patch was just integrated into master:
commit 79bff70ac829f45b27650671f9c33028c4b8f6c7
Author: Julius Werner <jwerner(a)chromium.org>
Date: Thu Aug 15 17:34:45 2013 -0700
exynos5: Refactor board-specific parts out of USB PHY code
This patch moves around some of the existing Exynos5 USB 2.0 PHY code
to make it cleaner in preparation of the 3.0 PHYs. It moves the VBUS
GPIOs (which are completely board-specific) into the mainboard code and
makes sure to only initialize PHYs on the boards that actually need
them. It also removes the USB 3.0 PLL hack that was needed on Snow from
the Pit and Kirby boards (which do not have that PLL anymore).
Change-Id: Ia35f47a765acff60481f0907f7448ec4f78e0937
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66887
Reviewed-by: Stefan Reinauer <reinauer(a)google.com>
(cherry picked from commit c3b1a8b687b535f4d5ac1b3bd2a4760151698fdb)
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/6609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
See http://review.coreboot.org/6609 for details.
-gerrit
the following patch was just integrated into master:
commit e9738dbe2bb564f7be7930aa5b01e9ae3c1e2288
Author: Julius Werner <jwerner(a)chromium.org>
Date: Thu Feb 21 13:41:40 2013 -0800
libpayload: Make USB transfer functions return amount of bytes
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack(a)chromium.org>
Reviewed-by: Stefan Reinauer <reinauer(a)google.com>
Tested-by: Gabe Black <gabeblack(a)chromium.org>
Commit-Queue: Gabe Black <gabeblack(a)chromium.org>
Updated the patch to support XHCI as well.
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
(cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458)
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/6390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
Reviewed-by: Patrick Georgi <patrick(a)georgi-clan.de>
See http://review.coreboot.org/6390 for details.
-gerrit
the following patch was just integrated into master:
commit 0f0c720621deacc3c51b409e10ea8100acc88c80
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Thu Aug 22 18:45:10 2013 -0700
exynos5420: ddr3: Cleanup init to use constants for directcmd
The old ddr3_mem_ctrl_init() for exynos5420 had hardcoded constants
for accessing directcmd registers. Modify to use #defines where
possible.
This is ported from: https://gerrit.chromium.org/gerrit/#/c/65616
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
Change-Id: I01567fc6941608a570832de97259c55e84942d01
Reviewed-on: https://gerrit.chromium.org/gerrit/66789
Commit-Queue: David Hendricks <dhendrix(a)chromium.org>
Tested-by: David Hendricks <dhendrix(a)chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich(a)chromium.org>
(cherry picked from commit d751e019f450172f060ce255ae53e972bc4a19ea)
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/6605
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan(a)alterapraxis.com>
See http://review.coreboot.org/6605 for details.
-gerrit
the following patch was just integrated into master:
commit 2f3daddd28c95a134f2543e366f8ee9dd8d2be41
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Tue Aug 20 17:13:01 2013 -0700
exynos5420: Alter init sequence as per recommendation
As per hardware recommendation, CKE PAD retention release must
happen just before gate leveling enable and only in case of resume.
Hence, this patch moves pad retention release from dmc_common.c to
dmc_init_ddr3_exynos5420.c. In addition to this we are providing
125 (+3 extra being safe) times auto refresh to DRAM by sending
REFA direct command. This is required because when CKE PAD retention
release happens, self refresh mode of DDR3 is disabled.
Hence, auto refresh 125 times.
This is ported from https://gerrit.chromium.org/gerrit/#/c/65573
Note: Since WAKEUP_DIRECT does not go thru memory init, it should be
safe to move CKE PAD retention out of bootblock.c.
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
Change-Id: Idec5d6fbbe3c6344d47401ba7203079c52a9b866
Reviewed-on: https://gerrit.chromium.org/gerrit/66788
Commit-Queue: David Hendricks <dhendrix(a)chromium.org>
Tested-by: David Hendricks <dhendrix(a)chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich(a)chromium.org>
(cherry picked from commit 96cbcb09245d4df92d3e1998704ab440be42df25)
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/6604
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix(a)chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan(a)alterapraxis.com>
See http://review.coreboot.org/6604 for details.
-gerrit
the following patch was just integrated into master:
commit ad4556f2cb429d921a9e00e3937797ea6f6f4cd8
Author: Julius Werner <jwerner(a)chromium.org>
Date: Wed Aug 21 17:33:31 2013 -0700
exynos5420: Make USB A-A booting work with early data cache
Apparently the IROM doesn't like data caches... the recently added
dcache-in-bootblock makes A-A booting fail, and flushes/invalidations
alone don't seem to fix it. It's pretty fast anyway, so we just disable
the cache again for the duration of the IROM call.
Also removes a superfluous invalidation line from the bootblock code...
dcache_mmu_enable/disable already take care of that.
Old-Change-Id: I35580d15664c7b4197d4ed14028720147adbf918
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66602
Reviewed-by: Gabe Black <gabeblack(a)chromium.org>
Reviewed-by: David Hendricks <dhendrix(a)chromium.org>
(cherry picked from commit e9c28a6a7a88c8286e62764ee5ad2694da2e822f)
exynos5: Implement booting from SDMMC media
This patch augments the alternative CBFS media source implementation for
Exynos5250 and Exynos5420 to allow booting from SDMMC devices (such as
an SD or uSD card reader, if available). It also moves MMC
initialization for the Snow, Pit and Kirby boards from romstage to
ramstage (mainboard_init) to prevent it from interfering with the IROM
during SDMMC boot.
Old-Change-Id: Ic4adef80c28262d084a53c28ec59aa7ac3af50c8
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66154
(cherry picked from commit 08de13b72432c076e3327c048df93d89d52b0ecc)
snow and pit: turn on FET4 (for SD card) at bootup
Explictly enable FET4 on Snow and Pit.
Historically we haven't needed to do this because:
* On snow there's a bypass around FET4 which effectively eliminates
it. Even if we don't turn on FET4 the SD card is still powered.
Turning on FET4 doesn't hurt though and is technically correct.
* On pit the EC turns on FET4 on cold bootup.
On pit we run into a problem if the kernel turns off FET4 like in
<https://gerrit.chromium.org/gerrit/#/c/65332/> and then we get a
software reset or warm reset. In this case the EC won't know to turn
it back on.
This was ported from: https://gerrit.chromium.org/gerrit/#/c/65673
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
Old-Change-Id: I57337f12b38889e6afee8577cf8807ec4c41e91c
Reviewed-on: https://gerrit.chromium.org/gerrit/66786
Commit-Queue: David Hendricks <dhendrix(a)chromium.org>
Tested-by: David Hendricks <dhendrix(a)chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich(a)chromium.org>
(cherry picked from commit e910117047d898b6b1d0dc965ef2ec0237d17646)
Squashed three commits for alternate cbfs SD support.
Change-Id: Idbd1fd4776cbf8cb20d03e6b691104cd8540a1ec
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/6530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
See http://review.coreboot.org/6530 for details.
-gerrit
Vladimir Serbinenko (phcoder(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/6627
-gerrit
commit 069f4434d5413f03b8cdd5afbc6cfafe9b0b6a00
Author: Vladimir Serbinenko <phcoder(a)gmail.com>
Date: Tue Aug 12 21:40:32 2014 +0200
i82801ix: Make RP04 optionally hotpluggable.
Change-Id: I34a1ae4bff22db6ee55fa511de39bdfd5dd92c7e
Signed-off-by: Vladimir Serbinenko <phcoder(a)gmail.com>
---
src/southbridge/intel/i82801ix/acpi/pcie.asl | 23 +++++++++++----
src/southbridge/intel/i82801ix/acpi/pcie_port.asl | 36 +++++++++++++++++++++++
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/src/southbridge/intel/i82801ix/acpi/pcie.asl b/src/southbridge/intel/i82801ix/acpi/pcie.asl
index 89d2485..f02ad02 100644
--- a/src/southbridge/intel/i82801ix/acpi/pcie.asl
+++ b/src/southbridge/intel/i82801ix/acpi/pcie.asl
@@ -26,7 +26,7 @@
Device (RP01)
{
NAME(_ADR, 0x001c0000) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
@@ -52,7 +52,7 @@ Device (RP01)
Device (RP02)
{
NAME(_ADR, 0x001c0001) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
@@ -79,7 +79,7 @@ Device (RP02)
Device (RP03)
{
NAME(_ADR, 0x001c0002) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
@@ -106,7 +106,7 @@ Device (RP03)
Device (RP04)
{
NAME(_ADR, 0x001c0003) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
@@ -127,13 +127,24 @@ Device (RP04)
}
}
+
+#ifdef RP04_IS_EXPRESSCARD
+ Device (SLOT)
+ {
+ Name (_ADR, 0x00)
+ Method (_RMV, 0, NotSerialized)
+ {
+ Return (0x01)
+ }
+ }
+#endif
}
Device (RP05)
{
NAME(_ADR, 0x001c0004) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
@@ -160,7 +171,7 @@ Device (RP05)
Device (RP06)
{
NAME(_ADR, 0x001c0005) // FIXME: Have a macro for PCI Devices -> ACPI notation?
- //#include "pcie_port.asl"
+#include "pcie_port.asl"
Method(_PRT)
{
If (PICM) {
diff --git a/src/southbridge/intel/i82801ix/acpi/pcie_port.asl b/src/southbridge/intel/i82801ix/acpi/pcie_port.asl
new file mode 100644
index 0000000..7c50bd6
--- /dev/null
+++ b/src/southbridge/intel/i82801ix/acpi/pcie_port.asl
@@ -0,0 +1,36 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2012 The Chromium OS Authors. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+/* Included in each PCIe Root Port device */
+
+OperationRegion (RPCS, PCI_Config, 0x00, 0xFF)
+Field (RPCS, AnyAcc, NoLock, Preserve)
+{
+ Offset (0x4c), // Link Capabilities
+ , 24,
+ RPPN, 8, // Root Port Number
+ Offset (0x5A),
+ , 3,
+ PDC, 1,
+ Offset (0xDF),
+ , 6,
+ HPCS, 1,
+}
Vladimir Serbinenko (phcoder(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/6626
-gerrit
commit 0ef593b9284a25db5aa7c84964d0406c36534138
Author: Vladimir Serbinenko <phcoder(a)gmail.com>
Date: Tue Aug 12 20:39:28 2014 +0200
gm45: Allow coexistance with ME firmware.
Change-Id: I08ca5eec94c70b43789122266d68af149772385c
Signed-off-by: Vladimir Serbinenko <phcoder(a)gmail.com>
---
src/mainboard/roda/rk9/Kconfig | 4 ++++
src/northbridge/intel/gm45/Kconfig | 11 +++++++++++
2 files changed, 15 insertions(+)
diff --git a/src/mainboard/roda/rk9/Kconfig b/src/mainboard/roda/rk9/Kconfig
index 733a320..6ed85ff 100644
--- a/src/mainboard/roda/rk9/Kconfig
+++ b/src/mainboard/roda/rk9/Kconfig
@@ -34,4 +34,8 @@ config MAX_CPUS
int
default 2
+config CBFS_SIZE
+ hex
+ default ROM_SIZE
+
endif # BOARD_RODA_RK9
diff --git a/src/northbridge/intel/gm45/Kconfig b/src/northbridge/intel/gm45/Kconfig
index 86249cc2..629bae3 100644
--- a/src/northbridge/intel/gm45/Kconfig
+++ b/src/northbridge/intel/gm45/Kconfig
@@ -34,6 +34,17 @@ config BOOTBLOCK_NORTHBRIDGE_INIT
string
default "northbridge/intel/gm45/bootblock.c"
+config CBFS_SIZE
+ hex "Size of CBFS filesystem in ROM"
+ default 0x100000
+ help
+ On GM45 systems the firmware image may
+ store a lot more than just coreboot, including:
+ - a firmware descriptor
+ - Intel Management Engine firmware
+ This option allows to limit the size of the CBFS portion in the
+ firmware image.
+
config VGA_BIOS_ID
string
default "8086,2a42"
Isaac Christensen (isaac.christensen(a)se-eng.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/6608
-gerrit
commit 569c8eab695cb37439fa8d2a89c5e011229b5fb1
Author: Julius Werner <jwerner(a)chromium.org>
Date: Thu Aug 22 16:24:09 2013 -0700
libpayload: ehci: Set explicit terminate bits in dummy_qh next pointers.
The EHCI host controllers in Samsung Exynos SoC seem to be a little more
picky than Intel ones. When they reach the dummy_qh in the periodic
frame list, they try to access the next qTD pointer even though it's
NULL, and run into a HostSystemError. This patch explicitly sets the
Terminate bit on those pointers to mark them invalid.
Change-Id: I50fa79bbf1c5fab306d7885c01efd66b13e279b8
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66884
Reviewed-by: Vincent Palatin <vpalatin(a)chromium.org>
(cherry picked from commit c575a5c958ce88732d28044352c89418bcd5ea86)
Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
---
payloads/libpayload/drivers/usb/ehci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/payloads/libpayload/drivers/usb/ehci.c b/payloads/libpayload/drivers/usb/ehci.c
index 0764592..af7daf1 100644
--- a/payloads/libpayload/drivers/usb/ehci.c
+++ b/payloads/libpayload/drivers/usb/ehci.c
@@ -793,6 +793,8 @@ ehci_init (unsigned long physical_bar)
memset((void *)EHCI_INST(controller)->dummy_qh, 0,
sizeof(*EHCI_INST(controller)->dummy_qh));
EHCI_INST(controller)->dummy_qh->horiz_link_ptr = QH_TERMINATE;
+ EHCI_INST(controller)->dummy_qh->td.next_qtd = QH_TERMINATE;
+ EHCI_INST(controller)->dummy_qh->td.alt_next_qtd = QH_TERMINATE;
for (i = 0; i < 1024; ++i)
periodic_list[i] = virt_to_phys(EHCI_INST(controller)->dummy_qh)
| PS_TYPE_QH;