On some flash chips data with addresses more than 24-bit field
can address may be accessed by using Extended Address Register.
The register has 1-byte size and stores high byte of 32-bit address.
Then flash can be read from 3-bytes addressing mode with writing
high byte of address to this Register. By using this way we have
access to full memory of a chip. Some chips may support this method
only.
This patch provides code use Extended Address Register.
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
flashrom.c
+ modified switch to 4-bytes addressing to support extended address register
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for write Extended Address Register
+ functions for read/write/erase with Extended Address Register
Change-Id: I09a8aa11de2ca14901f142c67c83c4fa0def4e27
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013200.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Here is the definition of new W25Q256xV chip with new functions pointers
for 4-bytes addressing reads and writes. Erase functions pointers are
changed in their old places. New feature flags for 4-bytes mode added.
Patched files
-------------
flashchips.c
+ added definition for Winbond W25Q256BV/W25Q256FV chips
Change-Id: I90226f453f8147ae5ac7dbbef7549ee3bfacc3d6
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013201.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20506
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch integrates code of the previous patch into Flashrom's code.
All the integrations is around 3 functions spi_nbyte_read, spi_nbyte_program
and spi_byte_program. After this patch then are not static and can be called
by their pointers saved in flashchips array. Also I added to flashrom.c some
code to switch a chip to 4-bytes addressing mode. And one error message is
corrected in spi.c because it's not suitable for 32-bit addresses.
Patched files
-------------
flash.h
+ added set of 4-bytes address functions to flashchip structure definition
flashrom.c
+ added switch to 4-bytes addressing more for chips which support it
serprog.c
+ added 4-bytes addressing spi_nbyte_read call to serprog_spi_read
spi.c
+ fixed flash chip size check in spi_chip_read
spi25.c
+ added 4-bytes addressing spi_nbyte_read call to spi_read_chunked
+ added 4-bytes addressing spi_nbyte_program call to spi_write_chunked
+ added 4-bytes addressing spi_byte_program call to spi_chip_write_1
Conflicts:
serprog.c
Change-Id: Ib051cfc93bd4aa7580519e0e6206d025f3ca8049
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013205.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20505
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix some whitespace, and braces. Remove sector size from comments that I
could not verify.
Change-Id: I4faaa036fea744135fa37f405686fb9fd0882806
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/21947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
If flash chip is switched to 4-bytes addressing mode then all
read/erase/program instructions will be switched from 3-bytes mode
to 4-bytes mode. Then well known instructions like 03h (Read),
02h (Program) and 20h,52h,D8h (Erase) will become one byte longer
and accept 4-bytes address instead of 3-bytes.
This patch provides support for well known instructions in 4-bytes
addressing mode. Also here is the code to enter 4-bytes addressing
mode by execute the instruction B7h (Enter 4-bytes mode).
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
Makefile
+ added spi4ba.c
Added files
-----------
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for enter 4-bytes addressing mode
+ functions for read/write/erase in 4-bytes addressing mode
Change-Id: Ie72e2a89cd75fb4d09f48e81c4c1d927c317b7a7
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013199.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20513
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
without the upcache there is no "offline" version (yet).
Change-Id: Iac3bf11fbd55cfa034ef8af04ef90fe57182ee2b
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
refine the pre-push hook:
- get rid of the concept of precious brances - all of them on the
upstream repos are precious (this is a change in the face of
using gerrit instead of a native git repository for staging purposes)
- likewise, only allow new versioned stable branches and no feature
branches there
Change-Id: I1d4b4a7ef2673cabee980ec4a7d7d5fbebdcaed1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- update the commit-msg hook to the latest one provided by Gerrit.
However, disable the (new) code that would avoid adding Change-IDs
to fixup/squash commits as needed on the staging branch
Change-Id: I2f2d7ae58dcd7d3e55959e18fe664df10bc3cc41
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21832
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- wrap a line in the hook installer. The line still exceeds our
maximum limit by two chars but it makes no sense to break
apart the one long argument IMHO
Change-Id: I0e931fbb5902d2714d5399c1d1bfac0de35523bb
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21831
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- exploit Make's -include statement to simplify execution flow
- expand and refine respective comment to better describe and
match the new behavior
Change-Id: I0c66f2508cc754cf9219211a06d6f305a32c422d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21830
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename getrevision's local_revision function to just revision.
All revisions are local in git and we certainly wont go back to
a non-distributed VCS :)
Change-Id: I6689ac24077b3981b471ed69de7cc3ef79d435b1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- make version string generation independent of the actual VCS
used by not generating "unknown" in the makefile but letting
getrevision do that
- make hook installation independent of version string generation
since they have nothing to do with each other and there are no
synergies anymore
Change-Id: Iedc9df4c033a70447b8b1b65c83764c769b02c3f
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use a more generic file name for the exported VCS data.
Change-Id: Ie57b20dc014ba44ded5783bdb432eb7d0e0e28ad
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix broken/one-off loop to restore file dates.
Explain what the sed program actually does because it is non-trivial.
Change-Id: Iff4021be49a9fab208b619c555b9f9e81f671ab8
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
"System Manager's Manual" or similar is way less interesting.
Change-Id: I45c5d6a2316c51a57a49fd010682dc3f0f915382
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21822
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A couple of C99-style variable declarations within loops are causing
compilation failures on some systems (gcc 4.9.2-10 on Raspbian). This
moves them to make gcc happy.
Change-Id: Ib7ad5a69244e462f84eae93df9e841716e089b31
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21702
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace bit shits with BIT() macro. This improves the readability of the
code.
Change-Id: I30315891f18d4d5bfbc247bb9012560479afab90
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Implements I210 "raw" flash access as detailed in:
http://www.intel.com/content/www/us/en/embedded/products/networking/i210-ethernet-controller-datasheet.html
Unfortunately, most of the time the card is in Secure Mode, which means
that the raw access is not available. But his should be pretty useful
for bringing up boards.
Change-Id: I8598ab21297b85dcae1e650a168043aa4cc15c10
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
On the I210 family there is no MAC EEprom, instead there is a big flash
(typically around 16Mb) with contents of the old MAC plus other stuff.
There is an interface to program the whole flash, but once it is
programmed it enters a "Secure Mode" that disables the interface.
Luckily, the section with the MAC can still be updated via the EEprom
interface. This patch adds support for this interface.
root@qt5022-fglrx:~# ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
flashrom v0.9.9-unknown on Linux 4.10.0-qtec-standard (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.4.1, GCC 5.3.0, little endian
Command line (5 args): ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
Calibrating delay loop... OS timer resolution is 1 usecs, 1856M loops per second, 10 myus = 10 us,
100 myus = 102 us, 1000 myus = 1017 us, 10000 myus = 10044 us, 4 myus = 4 us, OK.
Initializing nicintel_eeprom programmer
Found "Intel I210 Gigabit Network Connection" (8086:1533, BDF 01:00.0).
Requested BAR is of type MEM, 32bit, not prefetchable
Requested BAR is of type MEM, 32bit, not prefetchable
The following protocols are supported: Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Found Programmer flash chip "Opaque flash chip"
(4 kB, Programmer-specific) on nicintel_eeprom.
Found Programmer flash chip "Opaque flash chip" (4 kB, Programmer-specific).
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:W
Erase/write done.
Verifying flash... VERIFIED.
Change-Id: I553f33e5dcb4412d682fc93095b29bcfed11713c
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This patch has been tested on a board similar to AMD Bettong.
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 4a)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:790e] (rev 11)
root@qt5022-fglrx:~# ./flashrom -p internal -w kk.rom
flashrom v0.9.9-unknown on Linux 4.10.0-qtec-standard (x86_64)
flashrom is free software, get the source code at
https://flashrom.org
Calibrating delay loop... OK.
coreboot table found at 0x9ffd6000.
Found chipset "AMD FP4".
Enabling flash write... OK.
Found Micron/Numonyx/ST flash chip "N25Q128..1E" (16384 kB, SPI)
mapped at physical address 0x00000000ff000000.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
Change-Id: I66a240ebc8382cc7e5156686045aee1a9d03fe6d
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
5 regions made sense in 2013 when this bit of code was originally
written. MAX_NUM_FLREGS is now used to keep track of the max number of
flash regions and is >5 since Sunrise Point.
Change-Id: Idb559e618369fecf930724a7c1c84765247f3e38
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/21338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This moves the ich_layout declaration from one header to another. This
will avoid a circular dependency when we update the entries[] member in
the follow-up patch to use MAX_NUM_FLREGS which is defined in
ich_descriptors.h.
Change-Id: I08006f1f7c9ccdd17a9a6d74881ed2c8541d4de1
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/21337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This adds PCI IDs for C620-series PCHs and adds
CHIPSET_C620_SERIES_LEWISBURG as a new entry in the ich_chipset enum.
Lewisburg is very similar to Sunrise Point for Flashrom's purposes,
however one important difference is the way the "number of masters" is
interpreted from the flash descriptor (0-based vs. 1-based). There are
also new flash regions defined.
Change-Id: I96c89bc28bdfcd953229c17679f2c28f8b874d0b
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/20922
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Can't find bits that tell us the actual permissions in charge. So report
them as unknown.
Change-Id: Ib73f95e0348f5c6d89988e3ea3529af0ec3b23a6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/21106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The pci_dev structure is never meant to be used as is, but always as a
pointer. By using the struct itself in undo_pci_write_data, we are risking
data corruption, or buffer overflows if the structure size changes.
This is especially apparent on my system where flashrom segfaults
because I compile it with pciutils 3.3.0 and I run it on a system
with pciutils 3.5.2. The struture size is different and causes a
struct with the wrong size to be sent to the library, with invalid
internal field values.
This has been discovered and discussed in Change ID 18925 [1]
[1] https://review.coreboot.org/#/c/18925/
Change-Id: Icde2e587992ba964d4ff92c33aa659850ba06298
Signed-off-by: Youness Alaoui <kakaroto@kakaroto.homelinux.net>
Reviewed-on: https://review.coreboot.org/20784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Interpretation of component clocks changed. Also more regions and more
masters are supported now. The number of regions (NR) is now static per
chipset (10 in the 100 Series case) and not coded into the descriptor
any more.
v2: o Use guess_ich_chipset() for read_ich_descriptors_from_dump().
o Update region extraction in `ich_descriptors_tool`.
TEST=Run `ich_descriptors_tool` over a 100 Series dump and checked
that output looks sane. Run `ich_descriptors_tool` over dumps
of five different older systems (1 x Sandy Bridge, 3 x Ivy Bridge,
1 x Haswell). Beside whitespace changes, regions not accounted
by `NR` are not printed any more.
Change-Id: Idd60a857d1ecffcb2e437af21134d9de44dcceb8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18973
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add guess_ich_chipset() that takes fields from a descriptor dump and
returns the lowest possible chipset version.
Intel did several incompatible changes to the descriptor through the
years. However, they forgot to add a version number. So we have to
apply some heuristics to detect the chipset version in case of exter-
nal flashing.
Change-Id: Ie1736663dc33801b19d3e695c072c61a6c6345a2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20246
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The condition `base > limit` is still valid since `base` is always at
least 4096 greater than `limit` in this case.
Change-Id: I11ac0a50b3f32f47879e7cfb7a26068cd0572ede
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19046
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Sunrise Point PCH, paired with Skylake, has some minor changes
in the HW sequencing interface:
* Support for more flash regions moved PR* registers
* Only 4KiB erase blocks are supported by the primary erase command
* A second erase command for 64KiB pages was added
* More commands were added for status register access etc.
* A "Dedicated Lock Bits" register was added
No support for the new commands was added.
The SW sequencing interface seems to have moved register location and
is not supported any more officially. It's also untested.
Changes are loosely based on the Skylake support commit in Chromium OS
by Ramya Vijaykumar:
commit a9a64f9e4d52c39fcd3c5f7d7b88065baed189b1
Author: Ramya Vijaykumar <ramya.vijaykumar@intel.com>
flashrom: Add Skylake platform support
Change-Id: I0f4565a3c39f5fe3aec4fc8863605cebed1ad4ee
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
All publicly known Skylake / Kabylake / Sunrise Point PCH variants
share the same register interface [1..6]. Although all SPI configu-
ration is now done through the SPI PCI device 1f.5, we can't probe
for it directly since its PCI vendor and device IDs are usually hid-
den.
To work around the hidden IDs, we use another PCI accessor that doesn't
rely on the OS seeing the PCI device.
This handles SPI flashes only. While booting from LPC is still sup-
ported, it seems nobody uses it any more.
Some additional PCI IDs were gathered from driveridentifier.com.
TEST=Compiled with B150 set to NT (instead of BAD) and checked for
sane register readings.
[1] 6th Generation Intel® Core(TM) Processor Families I/O Platform
Datasheet - Volume 1 of 2
Revision 002EN
Document Number 332995
[2] 6th Generation Intel® Processor I/O Datasheet for U/Y Platforms
Volume 2 of 2
Revision 001EN
Document Number 332996
[3] 7th Generation Intel® Processor Families I/O Platform
Datasheet - Volume 1 of 2
Revision 002
Document Number 334658
[4] 7th Generation Intel® Processor Families I/O for U/Y Platforms
Datasheet - Volume 2 of 2
Revision 002
Document Number 334659
[5] Intel® 100 Series and Intel® C230 Series Chipset Family Platform
Controller Hub (PCH)
Datasheet - Volume 1 of 2
Revision 004EN
Document Number 332690
[6] Intel® 100 Series Chipset Family Platform Controller Hub (PCH)
Datasheet - Volume 2 of 2
Revision 001EN
Document Number 332691
Change-Id: I000819aff25fbe9764f33df85f040093b82cd948
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18925
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
Previous unnecessary page-by-page reading is repurposed to
read by big naturally aligned areas (now chip size limited
to 16MB for future-proofing of 4 byte addressed multi-die chips)
and serprog hack for continuous reads is removed.
Change-Id: Iadf909c9216578b1c5dacd4c4991bb436e32edc9
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-on: https://review.coreboot.org/20223
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is not different to other x-compilations.
Change-Id: Ia582b4cf622e670f1af439095ff58d62554232aa
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Reviewed-on: https://review.coreboot.org/20293
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Drop support for Subversion in the getrevision script and Makefile.
- Add .gitignore and .gitattributes file (the latter to limit exports).
- Restore modification dates of the exported files from the SCM.
- Stop exporting SCM log dumps to CHANGELOG. This makes no sense.
- Do not export the pre-"compiled" manpage. It can be generated like
anything else from the code dump when we export the respective
variable.
The latter is added with this change.
- Add some initial client-side git hooks
* When committing check for obvious stuff you never want anyway:
- white space errors
* When pushing to the upstream repository check mandatory rules:
- existing signoffs and acks in all new commits
- no deletions or creation of branches
- do not rewrite history of the precious branches, even if forced
NOTE: This patch is adapted from Stefan Tauner's original commit:
https://mail.coreboot.org/pipermail/flashrom/2016-November/014877.html
There are a few major differences:
- This uses coreboot's commit-msg hook which includes support for
generating and appending Change-Id.
- djgpp-dos target removal is moved to a follow-up patch.
- Version string changes are moved to a follow-up patch.
Change-Id: I64eef21982cac0a0a7419bcd2c8a936672ae9cb2
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/19206
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of calibrating our busy loop against a coarse clock, check if
a precise clock is available and loop against that. The former is unre-
liable by definition on any modern system that may dynamically reclock
the processor.
v2: Apparently _POSIX_MONOTONIC_CLOCK being defined only means that
the library knows about CLOCK_MONOTONIC. So check for its support
at runtime and fall back to CLOCK_REALTIME if it's missing.
TEST=Manually added a 10s loop and compared to real time. Run
on Linux RPi3, Linux x86 and my original use case Linux in
VirtualBox (Linux host).
Change-Id: I85ad359823875237ada9cd027af3017d62e9a235
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19391
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
o Move flashbuses_to_text() to flashrom.c, it's not a cli function.
o Guard `!defined(HAVE_STRNLEN)`. This guard was introduced in
23e10b87 (Add a bunch of new/tested stuff and various small
changes 24) to support older BSDs. It's probably completely
broken because HAVE_STRNLEN is presumably a GNU autotools
thing. But we can't fix it without retesting these older BSDs.
Change-Id: I561135209b819361d125eeaeef9ff886d6bae987
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18738
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a guard around read_ich_descriptors_via_fdo() which uses raw
hardware access and is only called from `ichspi`.
Fixes linking in case `NEED_RAW_ACCESS != 1`.
Change-Id: I5a35c607df44cdbcbacb960f8922c1bf9f1f2002
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20265
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The buffer passed to flashrom_image_write() isn't `const`. It might be
altered for full verification (with mixed contents if a layout is being
used).
Change-Id: Ibd8a9579e5dd859ae03b0deb3042b7035719e5de
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
It's never used and has no clear contract (e.g. will the pointer stay
valid beyond the call?).
Change-Id: I0d4e7cc731364e86eff214b9022b842a577f9ef4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19460
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The subtle difference was ignored when adding these chipsets. The
integrated Wildcat Point LP PCH is documented in [1].
I'm not sure how to account for "Broadwell H" which seems not publicly
documented. Maybe it's an unreleased HM9*, in which case the non-LP
path should be correct.
[1] Mobile 5th Generation Intel® Core(TM) Processor Family I/O,
Intel® Core(TM) M Processor Family I/O, Mobile Intel® Pentium® Processor
Family I/O, and Mobile Intel® Celeron® Processor Family I/O Datasheet
Revision 004
Document Number: 330837
Change-Id: I6b7ca3c0bde111b04ed7c745ed76d28d3d05f01c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18883
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
