Unfortunately stmicro.c does not distinguish the 1.8V version from
the 3.3V versions (yet) although they have distinct RDIDs.
I have at least ordered the ID macros accordingly and used a proper name
in this patch.
Change-Id: Id4fd8d46dcc9e51c1ae5504a32c2f8c5cfd863a1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/27861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Define a new spi_flash_ops structure, move all spi flash operations to
this structure and add a pointer to this structure in struct spi_flash.
BUG=b:38330715
Change-Id: I550cc4556fc4b63ebc174a7e2fde42251fe56052
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pointer to spi_slave structure can be passed in as const to spi flash
probe functions since the probe functions do not need to modify the
slave properties.
BUG=b:38330715
Change-Id: I956ee777c62dbb811fd6ce2aeb6ae090e1892acd
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19707
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of making all SPI drivers allocate space for a spi_flash
structure and fill it in, udpate the API to allow callers to pass in a
spi_flash structure that can be filled by the flash drivers as
required. This also cleans up the interface so that the callers can
maintain and free the space for spi_flash structure as required.
BUG=b:38330715
Change-Id: If6f1b403731466525c4690777d9b32ce778eb563
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new member page_size to spi_flash structure so that the various
spi flash drivers can store this info in spi_flash along with the
other sizes (sector size and total size) during flash probe. This
removes the need to have {driver}_spi_flash structure in every spi
flash driver.
This is part of patch series to clean up the SPI flash and SPI driver
interface.
BUG=b:38330715
Change-Id: I0f83e52cb1041432b0b575a8ee3bd173cc038d1f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
spi_crop_chunk is a property of the SPI controller since it depends
upon the maximum transfer size that is supported by the
controller. Also, it is possible to implement this within spi-generic
layer by obtaining following parameters from the controller:
1. max_xfer_size: Maximum transfer size supported by the controller
(Size of 0 indicates invalid size, and unlimited transfer size is
indicated by UINT32_MAX.)
2. deduct_cmd_len: Whether cmd_len needs to be deducted from the
max_xfer_size to determine max data size that can be
transferred. (This is used by the amd boards.)
Change-Id: I81c199413f879c664682088e93bfa3f91c6a46e5
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19386
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: coreboot org <coreboot.org@gmail.com>
There was an assumption that all SPI controllers could
consume a full page of data to write. However, that
assumption doesn't hold when spi_crop_chunk() indicates
sizes smaller than page size. If the requested offset isn't
page aligned from the start then writes will fail corrupting
data since a page boundary isn't honored.
The spansion driver needed quite a bit more work to honor
the spi_crop_chunk() result. It now mimics the other
driver's code. Also, needed to add spi_crop_chunk() to
marvell/bg4cd SoC to make google/cosmos build. SPI obviously
doesn't work on that platform, but it fixes the build error.
Change-Id: I93e24a5a717adcee45a017c164bd960f4592ad50
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17910
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Commit 36b81af (spi: Pass pointer to spi_slave structure in
spi_setup_slave) changes the way spi_setup_slave handles the spi_slave
structure. Instead of expecting spi controller drivers to maintain
spi_slave structure in CAR_GLOBAL/data section, caller is expected to
manage the spi_slave structure. This requires that spi_flash drivers
maintain spi_slave structure and flash probe function needs to make a
copy of the passed in spi_slave structure.
This change fixes the regression on Lenovo X230 and other mainboards.
Change-Id: I0ad971eecaf3bfe301e9f95badc043193cc27cab
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17728
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Iru Cai <mytbk920423@gmail.com>
RW flag was added to spi_slave structure to get around a requirement on
some AMD flash controllers that need to group together all spi volatile
operations (write/erase). This rw flag is not a property or attribute of
the SPI slave or controller. Thus, instead of saving it in spi_slave
structure, clean up the SPI flash driver interface. This allows
chipsets/mainboards (that require volatile operations to be grouped) to
indicate beginning and end of such grouped operations.
New user APIs are added to allow users to perform probe, read, write,
erase, volatile group begin and end operations. Callbacks defined in
spi_flash structure are expected to be used only by the SPI flash
driver. Any chipset that requires grouping of volatile operations can
select the newly added Kconfig option SPI_FLASH_HAS_VOLATILE_GROUP and
define callbacks for chipset_volatile_group_{begin,end}.
spi_claim_bus/spi_release_bus calls have been removed from the SPI flash
chip drivers which end up calling do_spi_flash_cmd since it already has
required calls for claiming and releasing SPI bus before performing a
read/write operation.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Idfc052e82ec15b6c9fa874cee7a61bd06e923fbf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17462
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Although we have already support for the flash chip N25Q128 there is a
similar type available which has the same geometry and opcodes but
unfortunately a slightly different device type ID. While the already
supported N25Q128 has the ID 0xbb18 this one has the ID 0xba18.
To make both types available in the flash support table, use N25Q128A as
the flash name. This name can be found in the datasheet which can be
found here:
https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_3v_65nm.pdf
TEST=Booted and verified that MRC cache could be written
Change-Id: I02a47692efb23a9a06a289c367488abd256b8e0c
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16061
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The 'A' indicates the production process(64 nm). All other chips from
the same family leave this out.
TEST=Build and booted on Minnowboard Max
Change-Id: I21e6c01de5d547bbc2252e679a001948e7ab752c
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10078
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
'.op_erase' was not specified for this chip. Set it to sub sector
erase(CMD_M25PXX_SSE). Adjust page/sector size for sub sector erase
to work.
TEST=Untested, due to lack of hardware.
Change-Id: Icc2748fbd3afeb56693e1c17d97eb490fba67064
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10077
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
What is described by the comment has already been fixed in f0d038f4
(flash: use two bytes of device ID to identify stmicro chips).
This also means that STM_ID_N25Q128 doesn't have to be at the top of
stmicro_spi_flash_table anymore.
TEST=Untested, due to lack of hardware
Change-Id: I7a9e9a0cdfdb1cf34e914e186fc6957c1d9b5ca6
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10068
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Bootblock does not allow using malloc, use statically allocated chip
structures instead.
BRANCH=storm
BUG=chrome-os-partner:33489
TEST=both drivers compile when configured in, also booted whirlwind
with an STM compatible SPI NOR flash.
Change-Id: I154c33ce5fc278d594205d8b8e62a56edb4e177e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eedbb959a595e0898e7a1dd551fc7c517a02f370
Original-Change-Id: I29b37107ac1d58a293f531f59ee76b3d8c4b3e7c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/248992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A payload may want to run erase operations on SPI NOR flash without
re-probing the device to get its properties. This patch passes up
three properties of flash to achieve that:
- The size of the flash device
- The sector size, i.e., the granularity of erase
- The command used for erase
The patch sends the parameters through coreboot and then libpayload.
The patch also includes a minor refactoring of the flash erase code.
Parameters are sent up for just one flash device. If multiple SPI
flash devices are probed, the second one will "win" and its
parameters will be sent up to the payload.
TEST=Observed parameters to be passed up to depthcharge through
libpayload and be used to correctly initialize flash and do an erase.
TEST=Winbond and Gigadevices spi flash drivers compile with the changes;
others don't, for seemingly unrelated reasons.
BRANCH=none
BUG=chromium:446377
Change-Id: Ib8be86494b5a3d1cfe1d23d3492e3b5cba5f99c6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126
Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239570
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This consolidates all calls to spi_claim_bus() and spi_release_bus()
to a single location where spi_xfer() is called. This avoids confusing
(and potentially redundant) calls that were being done throughout the
generic spi_flash.c functions and chip-specific functions.
I don't think the current approach could even work since many chip
drivers assert /CS once and then issue multiple commands such as page
program followed by reading the status register. I suspect the reason
we didn't notice it on x86 is because the ICH/PCH handled each
individual command correctly (spi_claim_bus() and spi_release_bus()
are noops) in spite of the broken code.
BUG=none
BRANCH=none
TEST=tested on nyan and link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3257e2f6a2820834f4c9018069f90fcf2bab05f6
Original-Reviewed-on: https://chromium-review.googlesource.com/194510
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit d3394d34fb49e9e252f67371674d5b3aa220bc9e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieb62309b18090d8f974f91a6e448af3d65dd3d1d
Reviewed-on: http://review.coreboot.org/7829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Support added for Micron N25Q128 SPI flash, which has
the same manufacturer id as ST Micro. Jedec ID =
0x20 0xBB 0x18. Since existing stmicro.c only compares
the last device id byte, this flash is mistakenly
identified as M25P128, which has ID = 0x20 0x20 0x18.
To handle this situation and avoid breaking code for
existing devices, a two byte .id member is added.
New devices should be added to the beginning of the
flash table array with .idcode = STM_ID_USE_ALT_ID and
.id = the two byte jedec device id.
A 4KB subsector erase capability is added and used for
this new device. It requires using a different SPI
op-code supported by adding .op_erase member. Previous
devices defined in stmicro.c are assigned their original
op-code for 64KB sector erase.
N25Q128 is now working on a custom designed Bayley Bay
based board. Tested by verifying the MRC fastboot cache
is successfully (re)written. Note that previous devices
were not retested.
Change-Id: Ic63d86958bf8d301898a157b435f549a0dd9893c
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7077
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
SPI controllers in Intel and AMD bridges have a slightly different
restriction on how long transactions they can handle.
Change-Id: I3d149d4b7e7e9633482a153d5e380a86c553d871
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6163
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
There are two separate restrictions to take into account:
Page Program command must not cross address boundaries defined by the
flash part's page size.
Total number of bytes for any command sent to flash part is restricted
by the SPI controller capabilities.
Consider
CONTROLLER_PAGE_LIMIT=64, page_size=256, offset=62, len=4.
This write would be split at offset 64 for no reason.
Consider
CONTROLLER_PAGE_LIMIT=40, page_size=256, offset=254, len=4.
This write would not be split at page boundary as required.
We do not really hit the second case. Nevertheless, CONTROLLER_PAGE_LIMIT
is a misnomer for the maximum payload length supported by the SPI controller
and is removed in a followup.
Change-Id: I727f2e7de86a91b6a509460ff1f374acd006a0bc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6162
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Ported from spi/winbond.c.
Fixes this error:
ICH SPI: Too much to write.
Does your SPI chip driver use CONTROLLER_PAGE_LIMIT?
Change-Id: I50db8fd1104d3b7d319b278b14f97e3ff9cb6404
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3877
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
The SB800 and Hudson now support adding the IMC ROM which runs from the same
chip as coreboot. When the IMC is running, write or erase commands sent to
the spi bus will fail, and the IMC will die. To fix this, we send a request
to the IMC to stop fetching from the SPI rom while we write to it. This
process (in one form or another) is required for writes to the SPI bus while
the IMC is running.
Because the IMC can take up to 500ms to respond every time we claim the
bus, this patch tries to keep the number of times we need to do that to a
minimum. We only need to claim the bus on writes, and using a counter for
the semaphore allows us to call in once to claim the bus at the beginning
of a number of transactions and it will stay claimed until we release it
at the end of the transactions.
Claim() - takes up to 500ms hit
claim() - no delay
erase()
release()
claim() - no delay
write()
release()
Release()
Change-Id: I4e003c5122a2ed47abce57ab8b92dee6aa4713ed
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1976
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Fix debug printks which were not using CONFIG_DEBUG_SPI_FLASH,
which would cause long delays durring boot when SPI devices
were written.
Change-Id: I99fc3d5f847fdf4bb98e2a0342ea418ab7d5fc54
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1965
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Only print PP: lines if CONFIG_DEBUG_SPI_FLASH is enabled.
Change-Id: If25e916ecb585f37c90d42980e933a6cd1a3d956
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- use %zu instead of %zd for size_t (%zd is for ssize_t)
- use %x instead of %lx for u32
- break some long lines to avoid commit hook trouble
Change-Id: Idfad716523dbcd2a595d26317240e972b5253e8b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1041
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This driver is taken from u-boot and adapted to match
coreboot. It still contains some hacks and is ICH specific
at places.
Change-Id: I97dd8096f7db3b62f8f4f4e4d08bdee10d88f689
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/997
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
