Coreboot uses the subvendor VID/DID of the Thinkpad X220-Tablet for
all X220 variants. Don't specify a dmidecode string so that it can be
used with coreboot on all X220 variants and on X220-Tablet with vendor
firmare.
Change-Id: Idd667da8209a664469c1a909a549d2b625714a78
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
There are older versions of git-rev-parse that don't understand the
`--git-path` switch. Also, when the install script was written, git-
rev-parse had a bug when it wasn't run from the root directory. They
fixed the behaviour by now. To simplify things and not have to account
for that too, we just bail out when the script is run from a sub-
directory.
Change-Id: I7ee8d4d54db48f7207fe8abf895c7fbba7685ad2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This adds support for W25P80/16/32 chips. Most notably these chips only
have two erase commands - one for 64KiB "sectors" and one for chip
erase.
Change-Id: Ie09ba8e28fee35c42e17ca05219dc673413de93b
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/23700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When developing software that has to be flashed to a flash chip to be
executed, it often takes a long time to read the current flash contents
(for flashrom to know what pages to erase and reprogram) each time
when writing the new image. However, when the flash was just reprogrammed,
its current state is known to be the previous image that was flashed
(assuming it was verified).
Thus, it makes sense to provide that image as a file for the flash contents
instead of wasting valuable time read the whole flash each time.
Change-Id: Idf153b6955f37779ae9bfb228a434ed10c304947
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23263
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of just "Probing for ENE KB9012 (EDI), 128 kB:", lets print
some debug info - like it is currently being printed for other chips:
Probing for ENE KB9012 (EDI), 128 kB: edi_chip_probe: hwversion 0xc3, ediid 0x04
Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
Change-Id: Id8e62bc9f6785b4bf0be0aaf0f74c8120d77c0d4
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23261
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ENE chips enable EDI by detecting a clock frequency between 1 MHz and 8 MHz.
In many cases, the chip won't be able to both detect the clock signal and
serve the associated request at the same time.
Thus, a dummy read has to be added to ensure that EDI is enabled and
operational starting from the next request.
Change-Id: I69ee71674649cd8ba4fc635f889cb39a1cd204b9
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23260
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ENE Embedded Debug Interface (EDI) is a SPI-based interface for
accessing the memory of ENE embedded controllers.
The ENE KB9012 EC is an embedded controller found on various laptops
such as the Lenovo G505s. It features a 8051 microcontroller and
has 128 KiB of internal storage for program data.
EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO)
when flash direct access is not in use. Some firmwares disable EDI at runtime
so it might be necessary to ground pin 42 to reset the 8051 microcontroller
before accessing the KB9012 via EDI.
The example of flashing KB9012 at Lenovo G505S laptop could be found here:
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
Change-Id: Ib8b2eb2feeef5c337d725d15ebf994a299897854
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Most flash chips are erased to ones and programmed to zeros. However, some
other chips, such as the ENE KB9012 internal flash, work the opposite way.
Change-Id: Ia7b0de8568e31f9bf263ba0ad6b051e837477b6b
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23258
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default, we want to probe for SPI25 chips only. Other SPI use cases,
like the ENE/EDI protocol, might use commands that can confuse these
common chips.
Now, flashrom will probe for a chip only if one of these conditions is
true:
1) no chip has been specified AND the chip uses the SPI25 commands
2) this chip has been specified by -c | --chip <chipname>
The CLI can later be extended to probe for a specific class of chips.
Change-Id: I89a53ccaef2791a2ac32904d7ab813da7478a6f0
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
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>
I can confirm a successful reading and writing of MX25L8005 (SPI) on a HP t5550
Thin Client (AMI BIOS 786R9 v1.04).
Change-Id: I190253b0c1920747b710ed7155e78191cce139eb
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23030
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Avoid attempting to read the SPI bases from the location 0x00000000, all
zeroes mean that the chipset's MMIO area is not enabled.
Change-Id: I5d3a1ba695153e854e0979ae634f8ed97e6b6293
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Advertise all 4BA features that are currently supported by flashrom,
plus add a new feature flag for the 4BA fast-read instruction. Also,
list all supported 3BA and 4BA erase-block functions.
As this adds a lot of new code paths that could be taken for these
chips, mark them all as untested again.
Change-Id: I0598496ee7058e3b170684d366f58e4014e0e871
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Instead of arbitrarily deciding whether to enter 4BA mode in the flash
chip's declaration, advertise that entering 4BA mode is supported and
only enter it if the SPI master supports 4-byte addresses. If not, exit
4BA mode (the chip might be in 4BA mode after reset). If we can't assure
the state of 4BA mode, we bail out to simplify the code (we'd have to
ensure that we don't run any instructions that can usually be switched
to 4BA mode otherwise).
Two new feature flags are introduced:
* FEATURE_4BA_ENTER:
Can enter/exit 4BA mode with instructions 0xb7/0xe9 w/o WREN.
* FEATURE_4BA_ENTER_WREN
Can enter/exit 4BA mode with instructions 0xb7/0xe9 after WREN.
FEATURE_4BA_SUPPORT is dropped, it's completely implicit now.
Also, draw the with/without WREN distinction into the enter/exit
functions to reduce code redundancy.
Change-Id: I877fe817f801fc54bd0ee2ce4e3ead324cbb3673
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
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>
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>
Stefan Tauner
Arthur Heymans
David Hendricks
Nico Huber
nybash
Leah Rowe
Paul Kocialkowski
Mike Banon
Lubomir Rintel
Shawn Anastasio
Rudolf Marek