With this, register_opaque_master can take care of register_shutdown
as well, and every opaque master only needs to call
register_opaque_master instead of calling both register_opaque_master
and register_shutdown.
Next patches in the chain convert opaque masters to use new API.
BUG=b:185191942
TEST=builds and ninja test from CB:56413
Change-Id: I34183e6bafc787eec54ee4a26b73a40803f3ce99
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
With this, register_spi_master can take care of register_shutdown
as well, and every spi master only needs to call register_spi_master
instead of calling both register_spi_master and register_shutdown.
Testing:
In dummyflasher, comment out free(data) in shutdown. Test fails with error:
../dummyflasher.c:949: note: block 0x55e0727a6e40 allocated here
ERROR: dummy_init_and_shutdown_test_success leaked 1 block(s)
Means, shutdown function is invoked for drivers with "old" API
(so, transitioning from old to new API is not breaking anything).
Next patches in the chain converts spi masters to use new API.
BUG=b:185191942
TEST=builds and ninja test
Change-Id: I2dc80dceca2f8204bcd0dad1f51753d7e79f1af5
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55932
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The definition of external structs doesn't have to be guarded.
See discussion under review.coreboot.org/52946.
Change-Id: I01e6a785269c3e0bd648eeaee217a7a855ab0853
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Allows us to move the individual entries into their respective driver files.
Change-Id: Ifbb0ee4db5a85b1cd2afeafe4dca838579f79878
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Makes the array size known to other compilation units.
Change-Id: Idacb4b7b0dd98af8bc7cbecf567d33daafb4b24d
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55116
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This way every bitbang spi master has access to its own spi data,
and can use this data in all its functions.
This patch only changes the signatures of functions.
BUG=b:185191942
TEST=builds
Change-Id: Id5722a43ce20feeed62630ad80e14df7744f9c02
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This allows the users of register_spi_bitbang_master() API to pass
their spi data into the API, and then the data can go further, into
register_spi_master() API.
BUG=b:185191942
TEST=builds
Change-Id: I13e83ae74dbc3a3e79c84d1463683d360ff47bc0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
It was impossible to register a const struct opaque_master that would
point to dynamically allocated `data`. Fix that so that we won't
have to create more mutable globals.
BUG=b:185191942
TEST=builds
Change-Id: Id3adb4cf04ae04dbe87ddb96f30871cb5f7c8ff0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54170
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It was impossible to register a const struct par_master that would
point to dynamically allocated `data`. Fix that so that we won't
have to create more mutable globals.
BUG=b:185191942
TEST=builds
Change-Id: I95bc92f6c54c5bcdac1c522ca87054aaffed0f40
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
When `CHIPSET_400_SERIES_COMET_POINT` got added, the `chipset_names`
table was not updated. Add the missing entry and reorder it to be
next to `CHIPSET_300_SERIES_CANNON_POINT` for consistency.
Change-Id: I4f4b31ecf91c432a2e82a92e274cb91ac166e635
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
The SPI hardware is pretty much unchanged from Apollo Lake. However, the
IFD differs significantly enough to require special handling.
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: Ib5dcdf204166f44a8531c19b5f363b851d2ccd77
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54276
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It was impossible to register a const struct spi_master that would
point to dynamically allocated `data`. Fix that so that we won't
have to create more mutable globals.
Change-Id: I0c753b3db050fb87d4bbe2301a7ead854f28456f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Convert the anon union of registered masters in the mst
field of the flashctx to a anon struct. If we are going
to dereference a pointer there in an undefined way we
should crash and not plow ahead with invalid memory.
The user of the registered_masters type is therefore
responsible for querying the buses_supported field before
attempting to dereference a ptr field in the anon struct.
BUG=b:175849641
TEST=`flashrom -p internal --flash-name`
Change-Id: I576967a8599b923c902e39f177f39146291cc242
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50246
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Removes unused declaration of noop_shutdown(). The implementation was
removed in 386cc556a4 and this declaration ought to have been removed at
the same time.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I7599ace08f3635251a80612df4b4d29001f81d35
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49800
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The opaque data pointer need not necessarily have constant
data for the life-time of the specific master. This is because
the data field purpose is for the master to use as it sees fit
for managing its own internal state and therefore we should not
constrain this as being RO data at init time.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I686c3c79547e35d48f3fd0b524fc98c176dcea6e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49131
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Unfortunately raiden_debug was upstreamed with a slightly
incorrect name of "raiden_debug" whereas in ChromiumOS
it is known as "raiden_debug_spi" and so correct this to
align. This avoids confusion and divergence for a unified
future.
Change-Id: I0eca35863403c5d4adbe19b31801e8dfa072006f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Unfortantly raiden_debug was upstreamed with a misnaming
of the CONFIG_ make param that introduces unnecessary divergence.
Rename to 'CONFIG_RAIDEN_DEBUG_SPI' as-is downstream.
Change-Id: I07c03647c329286bb223e4dae4665704e508db2c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Programmer enumerators and their corresponding programmer_table entries
need to be aligned. This was not the case for MEC1308 and ENE_LPC.
Their configs were not enabled by default until commit 26fde5b0b067
("ene_lpc,mec1308: Fix entry-points to be explicit")/CL:2488823,
allowing this issue to go unnoticed. The particular symptom of the
mismatch was internal_init() trying to init linux_mtd instead of
linux_spi.
BUG=b:172668501
TEST=flashrom -p host on gale
BRANCH=None
Original-Change-Id: I2e9d3df6a6fd6d5d8e3a5a13ee56f5997b10ea52
Original-Signed-off-by: Sam McNally <sammc@chromium.org>
Change-Id: I8e7a57b7c30e2dd2306d6fe7268eee8bb9d0c8a5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47353
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Victor Ding <victording@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromiumOS flashrom fork has since const'ify flashctx
in a few places. This aligns the function signatures to
match with downstream to ease forward porting patches
out of downstream back into mainline flashrom.
This patch is minimum viable alignment and so feedback is
welcome.
Change-Id: Iff6dbda13cb0d941481c0d204b9c30895630fbd1
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40324
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds support for the Parade lspcon usb-c to HDMI protocol
translater part that is i2c-controlled. The support allows the
host to reach the SPI ROM that hangs off the part where it
stores its firmware.
Usage is as follows:
flashrom -p lspcon_i2c_spi:bus=X
where X is the bus number.
BUG=b:148746232
BRANCH=none
TEST=tested with following commands, read/write/erase works good.
flashrom -p lspcon_i2c_spi:bus=7 -r /tmp/foo;
flashrom -p lspcon_i2c_spi:bus=7 -E;
flashrom -p lspcon_i2c_spi:bus=7 -w /tmp/foo;
Change-Id: I039e683252cfaf1ffef8694a3e8081b1b6b944f7
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The raiden_debug programmer is of type USB. However, it does not set the
field `devs.dev`, which will result in a segfault when trying to print
the devices of the non-existing table.
Fix that by replacing `devs.note` with `devs.dev` and adding an empty
device table. Since Device IDs are not used to match programmers,
nothing could be added to the table.
TEST=Running `flashrom -L` no longer segfaults and returns normally.
Change-Id: Ie4171a11384c34abb102d1aadf86aa1b8829fc04
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The board vendor and model are sometimes specified as arguments during
an internal flash, so make sure they are freed at the end of
initialization.
Change-Id: I9f43708f3b075896be67acec114bc6f390f8c6ca
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1230664, 1230665
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The Cannon Lake "300 Series" PCHs [1,2] share the register layout of the
Skylake "100 Series". Mark them as BAD until `ichspi.c` is adapted.
[1] Intel(R) 300 Series and Intel(R) C240 Series
Chipset Family Platform Controller Hub
Datasheet - Volume 1 of 2
Revison 4 (Dec 2018)
Document Number 337347
[2] Intel(R) 300 Series Chipset Families Platform Controller Hub
Datasheet - Volume 2 of 2
Revision 2? (Oct 2018)
Document Number 337348
Change-Id: If0b54799d5b93169ee660409bad57ae14677340c
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Jeremy Soller <jackpot51@gmail.com>
Mostly by changing to `unsigned` types where applicable, sometimes
`signed` types, and casting as a last resort.
Change-Id: I08895543ffb7a48058bcf91ef6500ca113f2d305
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
It works the same as 100 series PCHs and on. The SPI device is at
0:0d.2, though. Mark as BAD until `ichspi` is revised.
Change-Id: I7b1ad402ba562b7b977be111f8cf61f1be50843a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not needed anymore. Drop it fast before it encourages anyone to
violate layers again!
Change-Id: I8eda93b429e3ebaef79e22aba76be62987e496f4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33651
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We used to bail out on any unknown laptop. However, modern systems with
SPI flashes don't suffer from the original problem. Even if a flash chip
is shared with the EC, the latter has to expect the host to send regular
JEDEC SPI commands any time.
So instead of bailing out, we limit the set of buses to probe. If we
suspect to be running on a laptop, we only allow probing of SPI and
opaque programmers. The user can still use the existing force options
to probe all buses.
This will obsolete some board-enables that could be moved to `print.c`
in follow-up commits.
Change-Id: I1dbda8cf0c10d7786106f14f0d18c3dcce35f0a3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/28716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This is an interim solution. We'll have to enable 4BA step-by-step for
each dediprog protocol version.
Change-Id: I08efcbb09ab3499ef6902a698e9ce3d6232237c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Currently there is a TODO-like comment in the dediprog driver: "Might be
useful for other USB devices as well". Act on this comment by collecting
all the device discovery code for libusb1 devices into a separate file.
Change-Id: Idfcc79371241c2c1dea97faf5e532aa971546a79
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-on: https://review.coreboot.org/27443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The 96Boards Developerbox (a.k.a. Synquacer E-series) provides a CP2102
debug UART with its GPIO pins hooked up to the SPI NOR FLASH. The
circuit is intended to provide emergency recovery functions without
requiring any additional tools (such as a JTAG or SPI programmer). This
was expected to be very slow (and it is) but CP2102 is much cheaper than
a full dual channel USB comms chip.
Read performance is roughly on par with a 2400 baud modem (between 60
and 70 minutes per megabyte if you prefer) and write performance is 50%
slower still. The full recovery process, with backup and verification of
4MB data written takes between 14 and 15 hours. Thus it is only really
practical as an emergency recovery tool, firmware developers will need
to use an alternative programmer.
Change-Id: I2547a96c1a2259ad0d52cd4b6ef42261b37cccf3
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
On systems where the overhead of getting/setting pins is much greater
than the half period (for example, USB bit banging) it significantly
boosts performance if we can bang more than one bit at the same time.
Add support for setting sck at the same time as mosi or miso activity.
The speed up varies depending on how much the overhead of
getting/setting pins dominates execution time. For a USB bit bang driver
running on a 7th generation Core i5, the time to probe drops from ~9.2
seconds to ~7.7 seconds when set_clk_set_mosi() is implemented.
Change-Id: Ic3430a9df34844cdfa82e109456be788eaa1789a
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-on: https://review.coreboot.org/26946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This is driver that supports the Lattice iCE40 evaluation kits. On the
board is a SPI flash memory chip labeled ST 25P10VP.
Tested to work read/write/erase with "-p digilent_spi -c M25P10" or
with a patch that resets the part beforehands (in which case it gets
detected as a M25P10-A and is way faster due to paged writes).
Change-Id: I7ffcd9a2db4395816f0e8b6ce6c3b0d8e930c9e6
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This imports a series of patches from chromiumos for MTD support.
The patches are squashed to ease review and original Change-Ids have
been removed to avoid confusing Gerrit.
There are a few changes to integrate the code:
- Conflict resolution
- Makefile changes
- Remove file library usage from linux_mtd. We may revisit this and use
it for other Linux interfaces later on.
- Switch to using file stream functions for reads and writes.
This consolidated patch is
Signed-off-by: David Hendricks <dhendricks@fb.com>
The first commit's message is:
Initial MTD support
This adds MTD support to flashrom so that we can read, erase, and
write content on a NOR flash chip via MTD.
BUG=chrome-os-partner:40208
BRANCH=none
TEST=read, write, and erase works on Oak
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272983
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 2nd commit message:
linux_mtd: Fix compilation errors
This fixes compilation errors from the initial import patch.
Signed-off-by: David Hendricks <dhendricks@fb.com>
This is the 3rd commit message:
linux_mtd: Suppress message if NOR device not found
This just suppresses a message that might cause confusion for
unsuspecting users.
BUG=none
BRANCH=none
TEST=ran on veyron_mickey, "NOR type device not found" message
no longer appears under normal circumstances.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302145
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 4th commit message:
linux_mtd: Support for NO_ERASE type devices
Some mtd devices have the MTD_NO_ERASE flag set. This means
these devices don't require an erase to write and might not have
implemented an erase function. We should be conservative and skip
erasing altogether, falling back to performing writes over the whole
flash.
BUG=b:35104688
TESTED=Zaius flash is now written correctly for the 0xff regions.
Signed-off-by: William A. Kennington III <wak@google.com>
Reviewed-on: https://chromium-review.googlesource.com/472128
Commit-Ready: William Kennington <wak@google.com>
Tested-by: William Kennington <wak@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
This is the 5th commit message:
linux_mtd: do reads in eraseblock-sized chunks
It's probably not the best idea to try to do an 8MB read in one syscall.
Theoretically, this should work; but MTD just relies on the SPI driver
to deliver the whole read in one transfer, and many SPI drivers haven't
been tested well with large transfer sizes.
I'd consider this a workaround, but it's still good to have IMO.
BUG=chrome-os-partner:53215
TEST=boot kevin; `flashrom --read ...`
TEST=check for performance regression on oak
BRANCH=none
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344006
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is the 6th commit message:
linux_mtd: make read/write loop chunks consistent, and documented
Theoretically, there should be no maximum size for the read() and
write() syscalls on an MTD (well, except for the size of the entire
device). But practical concerns (i.e., bugs) have meant we don't quite
do this.
For reads:
Bug https://b/35573113 shows that some SPI-based MTD drivers don't yet
handle very large transactions. So we artificially limit this to
block-sized chunks.
For writes:
It's not clear there is a hard limit. Some drivers will already split
large writes into smaller chunks automatically. Others don't do any
splitting. At any rate, using *small* chunks can actually be a problem
for some devices (b:35104688), as they get worse performance (doing an
internal read/modify/write). This could be fixed in other ways by
advertizing their true "write chunk size" to user space somehow, but
this isn't so easy.
As a simpler fix, we can just increase the loop increment to match the
read loop. Per David, the original implementation (looping over page
chunks) was just being paranoid.
So this patch:
* clarifies comments in linux_mtd_read(), to note that the chunking is
somewhat of a hack that ideally can be fixed (with bug reference)
* simplifies the linux_mtd_write() looping to match the structure in
linux_mtd_read(), including dropping several unnecessary seeks, and
correcting the error messages (they referred to "reads" and had the
wrong parameters)
* change linux_mtd_write() to align its chunks to eraseblocks, not page
sizes
Note that the "->page_size" parameter is still somewhat ill-defined, and
only set by the upper layers for "opaque" flash. And it's not actually
used in this driver now. If we could figure out what we really want to
use it for, then we could try to set it appropriately.
BRANCH=none
BUG=b:35104688
TEST=various flashrom tests on Kevin
TEST=Reading and writing to flash works on our zaius machines over mtd
Change-Id: I3d6bb282863a5cf69909e28a1fc752b35f1b9599
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/505409
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: William Kennington <wak@google.com>
Reviewed-on: https://review.coreboot.org/25706
Tested-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
This patch sets the default baud rate for communication between
the host device and the Bus Pirate for hardware versions 3.0
and greater to 2M baud.
It also introduces the ability to manually set the baud rate via
the added 'serialspeed' programmer parameter.
This is done in two parts. Firstly, the requested serial speed is looked up
in a table to determine the appropriate clock divisor and the divisor is sent
to the bus pirate. Then, the system's baud rate for the selected serial port
is set using serial.c's 'serialport_config'. This function's prototype had to
be added to programmer.h.
In testing, using the 2M baud rate was able to significantly decrease
flash times (down from 20+ minutes to less than 2 minutes for an 8MB flash).
Change-Id: I3706f17a94fdf056063f2ad4a5f0a219665cdcbf
Signed-off-by: Shawn Anastasio <shawnanastasio@yahoo.com>
Reviewed-on: https://review.coreboot.org/23057
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a feature flag SPI_MASTER_4BA to `struct spi_master` that advertises
programmer-side support for 4-byte addresses in generic commands (and
read/write commands if the master uses the default implementations). Set
it for all masters that handle commands address-agnostic.
Don't prefer native 4BA instructions if the master doesn't support them.
Change-Id: Ife66e3fc49b9716f9c99cad957095b528135ec2c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
