Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11012
-gerrit
commit 8698fa0330b2260222a0372e451eb7bcf7731e02
Author: Jagadish Krishnamoorthy <jagadish.krishnamoorthy(a)intel.com>
Date: Sat Jul 18 11:46:37 2015 -0700
mec: Correct the access mode for short payloads
If the Host Command payload is less than 4 bytes
and is word aligned then the payload was not transferred at all.
EC reads the old packet and CRC mismatch occurs.
In this issue, the HC command packet
consisting of EC_CMD_REBOOT_EC as command and EC_REBOOT_COLD
as payload encountered the same problem as above.
Hence select byte access mode for shorter payloads.
BRANCH=None
BUG=chrome-os-partner:42396
TEST=System should boot after
chromeos-firmwareupdate
Change-Id: I22bdb739108d31b592c20247be69c198d617d359
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 8a43d2636b1bbfbac0384e1ea5e8853a7bd87a7f
Original-Change-Id: I5572093436f4f4a0fc337efa943753ab4642d8e4
Original-Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy(a)intel.com>
Original-Signed-off-by: Icarus Sparry <icarus.w.sparry(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286537
Original-Reviewed-by: Shawn N <shawnn(a)chromium.org>
---
src/ec/google/chromeec/ec_mec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ec/google/chromeec/ec_mec.c b/src/ec/google/chromeec/ec_mec.c
index 8a3b852..5d1ec3c 100644
--- a/src/ec/google/chromeec/ec_mec.c
+++ b/src/ec/google/chromeec/ec_mec.c
@@ -85,7 +85,7 @@ void mec_io_bytes(int write, u16 port, unsigned int length, u8 *buf, u8 *csum)
* Long access cannot be used on misaligned data since reading B0 loads
* the data register and writing B3 flushes it.
*/
- if (port & 0x3)
+ if ((port & 0x3) || (length < 4))
access_mode = ACCESS_TYPE_BYTE;
else
access_mode = ACCESS_TYPE_LONG_AUTO_INCREMENT;
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11017
-gerrit
commit a6da234d941ecbe4554ba8080a16ab8aefd3558b
Author: Tom Warren <twarren(a)nvidia.com>
Date: Fri Jul 17 08:19:18 2015 -0700
t132: Correct dma_busy function
In case of continuous mode, use STA_ACTIVITY bit to determine if DMA
operation is complete. However, in case of ONCE mode, use STA_BSY bit
to determine if DMA operation on the channel is complete.
This change was propogated from T210, commit ID 927026db
BUG=None
BRANCH=None
TEST=Ryu/Rush build OK.
Change-Id: I13073cc12ed0a6390d55b00c725d1cc7d0797e23
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: aab62d5148b57fd1e05c1e838eafe8fdee431ef8
Original-Change-Id: I7388e9fd73d591de50962aaefc5ab902f560fc6f
Original-Signed-off-by: Tom Warren <twarren(a)nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286468
Original-Reviewed-by: Furquan Shaikh <furquan(a)chromium.org>
---
src/soc/nvidia/tegra132/dma.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/soc/nvidia/tegra132/dma.c b/src/soc/nvidia/tegra132/dma.c
index 9f04e97..fb98692 100644
--- a/src/soc/nvidia/tegra132/dma.c
+++ b/src/soc/nvidia/tegra132/dma.c
@@ -69,9 +69,21 @@ int dma_busy(struct apb_dma_channel * const channel)
* In continuous mode, the BSY_n bit in APB_DMA_STATUS and
* BSY in APBDMACHAN_CHANNEL_n_STA_0 will remain set as '1' so long
* as the channel is enabled. So for this function we'll use the
- * DMA_ACTIVITY bit.
+ * DMA_ACTIVITY bit in case of continuous mode.
+ *
+ * However, for ONCE mode, the BSY_n bit in APB_DMA_STATUS will be used
+ * to determine end of dma operation.
*/
- return read32(&channel->regs->sta) & APB_STA_DMA_ACTIVITY ? 1 : 0;
+ uint32_t bit;
+
+ if (read32(&channel->regs->csr) & APB_CSR_ONCE)
+ /* Once mode */
+ bit = APB_STA_BSY;
+ else
+ /* Continuous mode */
+ bit = APB_STA_DMA_ACTIVITY;
+
+ return read32(&channel->regs->sta) & bit ? 1 : 0;
}
/* claim a DMA channel */
struct apb_dma_channel * const dma_claim(void)
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11016
-gerrit
commit a93cb2ac1a089d06b50b47ad07a98892e6f7b281
Author: Julius Werner <jwerner(a)chromium.org>
Date: Thu Jul 16 13:59:57 2015 -0700
libpayload: lz4: Add output overrun check to incompressible case
The LZ4 decompressor currently doesn't check for output overruns before
writing data in the case where a block had been incompressible (and
included verbatim in the compression stream). This is extremely unlikely
with the default 4MB blocks, but still a nice thing to fix. We'll still
output as much data as we can before returning an error to support
partial decompression use cases.
This matches the behavior already in place for normal, LZ4-compressed
blocks where the decompression function is already (supposed to be)
doing complete bounds checking (although it is not guaranteed to output
all valid bytes before aborting on an output overrun, and you should try
to provide a few dozen bytes of extra buffer space beyond the parts
you're interested in on partial decompression).
BRANCH=None
BUG=chrome-os-partner:32184
TEST=None
Change-Id: I5e40c8cec8947ec0ec8f6d8c8fa2574cfb4dc958
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 636985334c9b3b93a12d4066d2829f1f999c9315
Original-Change-Id: Iecf44650aade60b9fa1b13e57da752fb482a3f3f
Original-Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/286240
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
---
payloads/libpayload/liblz4/lz4_wrapper.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/payloads/libpayload/liblz4/lz4_wrapper.c b/payloads/libpayload/liblz4/lz4_wrapper.c
index b046597..431fb55 100644
--- a/payloads/libpayload/liblz4/lz4_wrapper.c
+++ b/payloads/libpayload/liblz4/lz4_wrapper.c
@@ -132,8 +132,12 @@ size_t ulz4fn(const void *src, size_t srcn, void *dst, size_t dstn)
return out - dst; /* decompression successful */
if (b.not_compressed) {
- memcpy(out, in, b.size);
- out += b.size;
+ size_t size = MIN((u32)b.size, dst + dstn - out);
+ memcpy(out, in, size);
+ if (size < b.size)
+ return 0; /* output overrun */
+ else
+ out += size;
} else {
/* constant folding essential, do not touch params! */
int ret = LZ4_decompress_generic(in, out, b.size,
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11015
-gerrit
commit 4cf5993c330c5e41786ab2f444707fff4eaa8b2b
Author: Jimmy Zhang <jimmzhang(a)nvidia.com>
Date: Mon Jul 13 14:10:18 2015 -0700
t210: Correct device MMIO range
Address region from 0x0 to 0x00ffffff is used for IROM_LOVEC and
can not be accessed by Bootloader.
Issue found in CL: 283104 is captured by this patch.
BUG=None
BRANCH=None
TEST=Compiles successfully and reboot test does not crash in firmware
Here are memory mapping table before and after this CL for evt2 board:
Before:
Mapping address range [0000000000000000:0000000040000000) as cacheable | read-write | secure | device
Mapping address range [0000000040000000:0000000040040000) as cacheable | read-write | non-secure | normal
Mapping address range [0000000040040000:0000000080000000) as cacheable | read-write | secure | device
Mapping address range [0000000080000000:00000000feb00000) as cacheable | read-write | non-secure | normal
Mapping address range [00000000fec00000:0000000100000000) as cacheable | read-write | secure | normal
Mapping address range [0000000100000000:0000000140000000) as cacheable | read-write | non-secure | normal
After:
Mapping address range [0000000001000000:0000000040000000) as cacheable | read-write | secure | device
Mapping address range [0000000040000000:0000000040040000) as cacheable | read-write | non-secure | normal
Mapping address range [0000000040040000:0000000080000000) as cacheable | read-write | secure | device
Mapping address range [0000000080000000:00000000feb00000) as cacheable | read-write | non-secure | normal
Mapping address range [00000000fec00000:0000000100000000) as cacheable | read-write | secure | normal
Mapping address range [0000000100000000:0000000140000000) as cacheable | read-write | non-secure | normal
Signed-off-by: Jimmy Zhang <jimmzhang(a)nvidia.com>
Change-Id: I07d38a8994c37bf945a68fb95a156c13f435ded2
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 3eee44944c2c83cc3530bfac0d71b86d3265f5b2
Original-Change-Id: I2b827064807ed715625af627db1826c3a01121ec
Original-Signed-off-by: Jimmy Zhang <jimmzhang(a)nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/285260
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/soc/nvidia/tegra210/include/soc/addressmap.h | 2 ++
src/soc/nvidia/tegra210/mmu_operations.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/soc/nvidia/tegra210/include/soc/addressmap.h b/src/soc/nvidia/tegra210/include/soc/addressmap.h
index 4a5372d..66888c6 100644
--- a/src/soc/nvidia/tegra210/include/soc/addressmap.h
+++ b/src/soc/nvidia/tegra210/include/soc/addressmap.h
@@ -30,6 +30,8 @@ enum {
};
enum {
+ TEGRA_ARM_PCIE_A1_BASE = 0x01000000,
+ TEGRA_ARM_LOWEST_PERIPH = TEGRA_ARM_PCIE_A1_BASE,
TEGRA_ARM_PERIPHBASE = 0x50040000,
TEGRA_GICD_BASE = 0x50041000,
TEGRA_GICC_BASE = 0x50042000,
diff --git a/src/soc/nvidia/tegra210/mmu_operations.c b/src/soc/nvidia/tegra210/mmu_operations.c
index 66a93e1..dd7437c 100644
--- a/src/soc/nvidia/tegra210/mmu_operations.c
+++ b/src/soc/nvidia/tegra210/mmu_operations.c
@@ -43,7 +43,7 @@ static void tegra210_memrange_init(struct memranges *map)
memory_in_range_below_4gb(&start,&end);
/* Device memory below DRAM */
- memranges_insert(map, 0, start * MiB, devmem);
+ memranges_insert(map, TEGRA_ARM_LOWEST_PERIPH, start * MiB, devmem);
/* DRAM */
memranges_insert(map, start * MiB, (end-start) * MiB, cachedmem);
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11014
-gerrit
commit d23415d015e8ba3d5ab95514a83a6e53ad0e993d
Author: Furquan Shaikh <furquan(a)google.com>
Date: Thu Jul 16 12:25:01 2015 -0700
arm64: Set LOG_LEVEL=0 for BL31 if coreboot does not use serial
Even if DEBUG=0, BL31 puts NOTICE(..) messages on serial console. Set
LOG_LEVEL=0 if coreboot does not use serial.
BUG=None
BRANCH=None
TEST=Compiles successfully and no console output from bl31 for
production images.
Change-Id: Ie77bcac3e2a0d314545b6811327c413536c77fb9
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: e8e3bcbf6249c80850a87dd66f34d3ff36158641
Original-Change-Id: I1415a3816cd2fa9dd05bcbd36ac0abc3f2759960
Original-Signed-off-by: Furquan Shaikh <furquan(a)google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286150
Original-Tested-by: Furquan Shaikh <furquan(a)chromium.org>
Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan(a)chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan(a)chromium.org>
---
src/arch/arm64/Makefile.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/arch/arm64/Makefile.inc b/src/arch/arm64/Makefile.inc
index 4cf012a..e7ee84c 100644
--- a/src/arch/arm64/Makefile.inc
+++ b/src/arch/arm64/Makefile.inc
@@ -192,6 +192,9 @@ endif
# Build ARM TF in debug mode (with serial output) if coreboot uses serial
ifeq ($(CONFIG_CONSOLE_SERIAL),y)
BL31_MAKEARGS += DEBUG=1
+else
+# Turn off NOTICE messages from BL31 if coreboot does not use serial
+BL31_MAKEARGS += LOG_LEVEL=0
endif # CONFIG_CONSOLE_SERIAL
# Avoid build/release|build/debug distinction by overriding BUILD_PLAT directly
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11012
-gerrit
commit fb7301e07627da965c55384c76b1817ecdfc6c9f
Author: Jagadish Krishnamoorthy <jagadish.krishnamoorthy(a)intel.com>
Date: Sat Jul 18 11:46:37 2015 -0700
mec: Correct the access mode for short payloads
If the Host Command payload is less than 4 bytes
and is word aligned then the payload was not transferred at all.
EC reads the old packet and CRC mismatch occurs.
In this issue, the HC command packet
consisting of EC_CMD_REBOOT_EC as command and EC_REBOOT_COLD
as payload encountered the same problem as above.
Hence select byte access mode for shorter payloads.
BRANCH=None
BUG=chrome-os-partner:42396
TEST=System should boot after
chromeos-firmwareupdate
Change-Id: I22bdb739108d31b592c20247be69c198d617d359
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 8a43d2636b1bbfbac0384e1ea5e8853a7bd87a7f
Original-Change-Id: I5572093436f4f4a0fc337efa943753ab4642d8e4
Original-Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy(a)intel.com>
Original-Signed-off-by: Icarus Sparry <icarus.w.sparry(a)intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286537
Original-Reviewed-by: Shawn N <shawnn(a)chromium.org>
---
src/ec/google/chromeec/ec_mec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ec/google/chromeec/ec_mec.c b/src/ec/google/chromeec/ec_mec.c
index 8a3b852..5d1ec3c 100644
--- a/src/ec/google/chromeec/ec_mec.c
+++ b/src/ec/google/chromeec/ec_mec.c
@@ -85,7 +85,7 @@ void mec_io_bytes(int write, u16 port, unsigned int length, u8 *buf, u8 *csum)
* Long access cannot be used on misaligned data since reading B0 loads
* the data register and writing B3 flushes it.
*/
- if (port & 0x3)
+ if ((port & 0x3) || (length < 4))
access_mode = ACCESS_TYPE_BYTE;
else
access_mode = ACCESS_TYPE_LONG_AUTO_INCREMENT;