summaryrefslogtreecommitdiffstats
path: root/spi.c
diff options
context:
space:
mode:
authorNico Huber <nico.h@gmx.de>2017-04-21 23:47:08 +0200
committerNico Huber <nico.h@gmx.de>2017-12-28 10:49:05 +0000
commited098d62d66d91cf7330a37f9b83e303eb7f56d8 (patch)
tree639b6233e588fd8b4150b42112da36e239ba7fa4 /spi.c
parent7e3c81ae7122120fe10d43fcba61a513e2461de9 (diff)
downloadflashrom-ed098d62d66d91cf7330a37f9b83e303eb7f56d8.tar.gz
flashrom-ed098d62d66d91cf7330a37f9b83e303eb7f56d8.tar.bz2
flashrom-ed098d62d66d91cf7330a37f9b83e303eb7f56d8.zip
spi: Move ICH BBAR quirk out of the way
Get rid of the layering violations around ICH's BBAR. Move all the weird address handling into (surprise, surprise) `ichspi.c`. Might fix writes for the `BBAR != 0` case by accident. Background: Some ICHs have a BBAR (BIOS Base Address Configuration Register) that, if set, limits the valid address range to [BBAR, 2^24). Current code lifted addresses for REMS, RES and READ operations by BBAR, now we do it for all addresses in ichspi. Special care has to be taken if the BBAR is not aligned by the flash chip's size. In this case, the lower part of the chip (from BBAR aligned down, up to BBAR) is inacces- sible (this seems to be the original intend behind BBAR) and has to be left out in the address offset calculation. Change-Id: Icbac513c5339e8aff624870252133284ef85ab73 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22396 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'spi.c')
-rw-r--r--spi.c47
1 files changed, 1 insertions, 46 deletions
diff --git a/spi.c b/spi.c
index 0a4a6184c..56f1fdf52 100644
--- a/spi.c
+++ b/spi.c
@@ -103,31 +103,7 @@ int default_spi_write_256(struct flashctx *flash, const uint8_t *buf, unsigned i
int spi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start,
unsigned int len)
{
- unsigned int addrbase = 0;
-
- /* Check if the chip fits between lowest valid and highest possible
- * address. Highest possible address with the current SPI implementation
- * means 0xffffff, the highest unsigned 24bit number.
- */
- addrbase = spi_get_valid_read_addr(flash);
- /* Show flash chip size warning if flash chip doesn't support
- 4-Bytes Addressing mode and last address excedes 24 bits */
- if (!(flash->chip->feature_bits & FEATURE_4BA_SUPPORT) &&
- addrbase + flash->chip->total_size * 1024 > (1 << 24)) {
- msg_perr("Flash chip size exceeds the allowed access window. ");
- msg_perr("Read will probably fail.\n");
- /* Try to get the best alignment subject to constraints. */
- addrbase = (1 << 24) - flash->chip->total_size * 1024;
- }
- /* Check if alignment is native (at least the largest power of two which
- * is a factor of the mapped size of the chip).
- */
- if (ffs(flash->chip->total_size * 1024) > (ffs(addrbase) ? : 33)) {
- msg_perr("Flash chip is not aligned natively in the allowed "
- "access window.\n");
- msg_perr("Read will probably return garbage.\n");
- }
- return flash->mst->spi.read(flash, buf, addrbase + start, len);
+ return flash->mst->spi.read(flash, buf, start, len);
}
/*
@@ -142,27 +118,6 @@ int spi_chip_write_256(struct flashctx *flash, const uint8_t *buf, unsigned int
return flash->mst->spi.write_256(flash, buf, start, len);
}
-/*
- * Get the lowest allowed address for read accesses. This often happens to
- * be the lowest allowed address for all commands which take an address.
- * This is a master limitation.
- */
-uint32_t spi_get_valid_read_addr(struct flashctx *flash)
-{
- switch (flash->mst->spi.type) {
-#if CONFIG_INTERNAL == 1
-#if defined(__i386__) || defined(__x86_64__)
- case SPI_CONTROLLER_ICH7:
- case SPI_CONTROLLER_ICH9:
- /* Return BBAR for ICH chipsets. */
- return ichspi_bbar;
-#endif
-#endif
- default:
- return 0;
- }
-}
-
int spi_aai_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len)
{
return flash->mst->spi.write_aai(flash, buf, start, len);