May 2024 - flashrom-gerrit - mail.coreboot.org

[L] Change in flashrom[main]: doc: Convert ME and Intel docs
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Anastasia Klimchuk has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/82649?usp=email ) Change subject: doc: Convert ME and Intel docs ...................................................................... doc: Convert ME and Intel docs ME page existed on wiki here https://wiki.flashrom.org/ME The contents are mostly unchanged, but one broken kernel link is removed from Intel doc. Change-Id: I79af5674f3af9ca880e89becd6a272a2cf8ed599 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> --- D Documentation/mysteries_intel.txt M doc/user_docs/index.rst A doc/user_docs/management_engine.rst A doc/user_docs/misc_intel.rst 4 files changed, 252 insertions(+), 173 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/49/82649/1 diff --git a/Documentation/mysteries_intel.txt b/Documentation/mysteries_intel.txt deleted file mode 100644 index 088abb8..0000000 --- a/Documentation/mysteries_intel.txt +++ /dev/null @@ -1,173 +0,0 @@ -= BBAR on ICH8 = - There is no sign of BBAR (BIOS Base Address Configuration Register) in the - public datasheet (or specification update) of the ICH8. Also, the offset of - that register has changed between ICH7 (SPIBAR + 50h) and ICH9 (SPIBAR + - A0h), so we have no clue if or where it is on ICH8. Out current policy is to - not touch it at all and assume/hope it is 0. - -= Software Sequencing vs. Hardware Sequencing and the "Opaque flash chip" = -Software sequencing and hardware sequencing are two methods used to interface -with the SPI controller on Intel platforms. They can be selected using either -ich_spi_mode=swseq or ich_spi_mode=hwseq programmer parameters. Flashrom will -attempt to automatically detect which mode to use. - -Software sequencing is the traditional method whereby software running on the -CPU handles most of the logic needed to interact with the flash chip. This -offers good flexibility since the user can utilize any opcode available in the -OPMENU registers, and OPMENU can be left unlocked or on coreboot-supported -platforms the owner of the system may program it for their needs before locking -it. Advanced or non-standard features of a chip such as write protection and -OTP may therefore be directly utilized by software. - -Hardware sequencing is a newer method (since around 2011) whereby most of the -logic for interacting with the SPI flash chip is contained within the SPI -controller itself and software such as flashrom may only select a few operations -chosen by Intel via the Flash Cycle (FCYCLE) field. The chip must conform to -specifications from Intel for each chipset/PCH. The specs are given in the -"SPI Programming Guide" application note. See [SPI_PROG] cited at the bottom of -this document for an example. - -Hardware sequencing simplifies things from a software perspective since the -software is guaranteed some minimal level of support and doesn't even need to -know the chip's ID or opcodes; it just needs to tell the SPI controller to -perform a type of transaction such as "read", "4k block erase", etc. Hence when -using hardware sequencing one will see "Opaque flash chip" as the chip's -description since software might not be able to identify the chip. The SPI -controller can combine multiple physical flash chips to logically appear as a -single large flash device, and in such cases it would not make sense for -flashrom to try to identify the chip. - -In many non-Intel systems the software has full control of a generic SPI -controller where the software controls the SPI signals and also constructs the -data payload including pre-op (e.g. write enable latch), opcode, address, and -data. Intel SPI flash controllers are purpose-built for flash chip access and -the software does not control the hardware directly. This makes Intel SPI -controllers less flexible from a software standpoint, however there are some -benefits such as guaranteed atomicity and multi-master arbitration needed for -modern Intel platforms where the CPU and various microprocessors can share the -same flash chip. - -= SMM BIOS Write Protection = -Sometimes a hardware vendor will enable "SMM BIOS Write Protect" (SMM_BWP) -in the firmware during boot time. The bits that control SMM_BWP are in the -BIOS_CNTL register in the LPC interface. - -When enabled, the SPI flash can only be written when the system is operating in -in System Management Mode (SMM). In other words, only certain code that was -installed by the BIOS can write to the flash chip. Programs that run in OS -context such as flashrom can still read the flash chip, but cannot write to the -flash chip. - -Flashrom will attempt to detect this and print a warning such as the following: -"Warning: BIOS region SMM protection is enabled!" - -Many vendor-supplied firmware update utilities do not actually write to the ROM; -instead they transfer data to/from memory which is read/written by a routine -running in SMM and is responsible for writing to the firmware ROM. This causes -severe system performance degradataion since all processors must be in SMM -context (ring -2) instead of OS context (ring 0) while the firmware ROM is being -written. - -= Accesses beyond region bounds in descriptor mode = - Intel's flash image tool will always expand the last region so that it covers - the whole flash chip, but some boards ship with a different configuration. - It seems that in descriptor mode all addresses outside the used regions can not - be accessed whatsoever. This is not specified anywhere publicly as far as we - could tell. flashrom does not handle this explicitly yet. It will just fail - when trying to touch an address outside of any region. - See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html - -= (Un)locking the ME region = - If the ME region is locked by the FRAP register in descriptor mode, the host - software is not allowed to read or write any address inside that region. - Although the chipset datasheets specify that "[t]he contents of this register - are that of the Flash Descriptor" [PANTHER], this is not entirely true. - The firmware has to fill at least some of the registers involved. It is not - known when they become read-only or any other details, but there is at least - one HM67-based board, that provides an user-changeable setting in the firmware - user interface to enable ME region updates that lead to a FRAP content that is - not equal to the descriptor region bits [NC9B]. - - There are different ways to unlock access: - - - A pin strap: Flash Descriptor Security Override Strap (as indicated by the - Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is - probably not accessible to end users on consumer boards (every Intel doc i - have seen stresses that this is for debugging in manufacturing only and - should not be available for end users). - The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of - the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL]. - - - Intel Management Engine BIOS Extension (MEBx) Disable - This option may be available to end users on some boards usually accessible - by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not - really disable it: it causes the Intel ME code to be halted at an early stage - of the Intel ME's booting so that the system has no traffic originating from - the Intel ME on any of the buses." [MEBX] The ME indicates this in - bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device - by setting them to 3 (Soft Temporary Disable) [MODE_CTRL]. - - - Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or - channel?) #0 disables the ME completely, which may give the host access to - the ME region. - - - HMRFPO (Host ME Region Flash Protection Override) Enable MEI command - This is the most interesting one because it allows to temporarily disable - the ME region protection by software. The ME indicates this in bits [19:16] - (Operation Mode) in the HFS register of the HECI/MEI PCI device by setting - them to 5 (SECOVER_MEI_MSG) [MODE_CTRL]. - -== MEI/HECI == - Communication between the host software and the different services provided by - the ME is done via a packet-based protocol that uses MMIO transfers to one or - more virtual PCI devices. Upon this layer there exist various services that can - be used to read out hardware management values (e.g. temperatures, fan speeds - etc.). The lower levels of that protocol are well documented: - The locations/offsets of the PCI MMIO registers are noted in the chipset - datasheets. The actually communication is documented in a whitepaper [DCMI] and - an outdated as well as a current Linux kernel implementation (currently in - staging/ exist [KERNEL]. There exists a patch that re-implements this in user - space (as part of flashrom). - -== Problems == - The problem is that only very few higher level protocols are documented publicly, - especially the bunch of messages that contain the HMRFPO commands is probably - well protected and only documented in ME-specific docs and the BIOS writer's - guides. We are aware of a few leaked documents though that give us a few hints - about it, but nothing substantial regarding its implementation. - - The documents are somewhat contradicting each other in various points which - might be due to factual changes in process of time or due to the different - capabilities of the ME firmwares, example: - - Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI - ME Region, to prevent both writing at the same time, causing data corruption." [ME8] - - "FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if - used to update the ME Region." [SPS] - - When looking at the various ME firmware editions (and different chipsets), things - get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST - (EOP), others say that the ME region can be updated in the field or that some - vendor tools use it for updates. This needs to be investigated further before - drawing any conclusion. - -[PANTHER] Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet - Document Number: 326776, April 2012, page 857 -[NC9B] Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked. - NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b". - http://paste.flashrom.org/view.php?id=1215 -[MODE_CTRL] Client Platform Enabling Tour: Platform Software - Document Number: 439167, Revision 1.2, page 52 -[MEBX] Intel Management Engine BIOS Extension (MEBX) User's Guide - Revision 1.2, Section 3.1 and 3.5 -[DCMI] DCMI Host Interface Specification - Revision 1.0 -[KERNEL] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=d… -[SPI_PROG] Ibex Peak SPI Programming Guide - Document Number: 403598, Revision 1.3, page 79 -[ME8] Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series - Revision 2.0, page 59 -[SPS] Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1 - for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware - Revision 2.2, page 51 diff --git a/doc/user_docs/index.rst b/doc/user_docs/index.rst index 5bc93d1..b61567a 100644 --- a/doc/user_docs/index.rst +++ b/doc/user_docs/index.rst @@ -7,3 +7,5 @@ fw_updates_vs_spi_wp example_partial_wp chromebooks + management_engine + misc_intel diff --git a/doc/user_docs/management_engine.rst b/doc/user_docs/management_engine.rst new file mode 100644 index 0000000..f1cf3fc --- /dev/null +++ b/doc/user_docs/management_engine.rst @@ -0,0 +1,45 @@ +====================== +ME (Management Engine) +====================== + +ME stands for Management Engine (or Manageability Engine) and refers to an Embedded Controller found in Intel chipsets. It uses different versions +of an `ARC <http://en.wikipedia.org/wiki/ARC_International>`_ 32-bit microcontroller that runs its own operating system independently from the user's. +The ME has access to all kinds of buses which allows for out-of-band processing which is used for features +like `Active Management Technology <http://en.wikipedia.org/wiki/Intel_Active_Management_Technology>`_, but it makes it also a very interesting target for black hats. +The firmware it runs is secured by certificates stored in ROM, but it is a complex beast and it is very unlikely that there is +no `way around its security measures <http://invisiblethingslab.com/resources/misc09/Quest%20To%20The%20Core%20(p…>`_ (intentional backdoors included). +For further details about the ME please see these excellent `slides by Igor Skochinsky <http://2012.ruxconbreakpoint.com/assets/Uploads/bpx/Breakpoint%202012%20Sko…>`_ +and the `Security Evaluation of AMT by Vassilios Ververis <http://web.it.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-Vassilios_Verve…>`_. + +Effects on flashrom +=================== + +The firmware of the ME usually shares the flash memory with the firmware of the host PC (BIOS/UEFI/coreboot). +The address space is separated into regions (similar to partitions on a harddisk). The first one (*Descriptor region*) +contains configuration data which contains something similar to a partition table and access rights for the different devices that can access the flash +(host CPU, ME, GbE controller). These restrictions are enforced by the chipset's SPI controller which is the main interface for flashrom +to access the flash chip(s) attached to the chipset. Intel recommends to set the descriptor region read-only and to forbid reads and writes to the ME region by the host CPU. +Writes by the host could interfere with the code running on the ME. This means that flashrom which runs on the host PC can not access +the ME firmware region of the flash at all in this configuration. flashrom detects that, warns the user and disables write access for safety reasons in that case. + +Unlocking the ME region +======================= + +There are a few ways to enable full access to the ME region, but they are not user friendly at all in general. Also, the Descriptor region is not affected by these actions, +so it is still not possible to access the complete flash memory even when the ME region is unlocked. For the different possibilities please see +the document :doc:`misc_intel`. + +Suggested workarounds +===================== + + * If you just want to update the proprietary firmware of the board use the vendor tool(s). + * If you need full access to the flash chip get an external programmer (see :doc:`/supported_hw/supported_prog/index`) and try in-circuit programming. + * If you only need to update the BIOS region, then you may use the options ``--ifd -i bios --noverify-all`` to write (and verify) only the BIOS region as described in the Intel flash descriptor. + +.. todo:: Migrate page for in-circuit programming (ISP) + +See also +======== + + * The respective `coreboot page on the management engine <http://www.coreboot.org/Intel_Management_Engine>`_ + * :doc:`misc_intel` diff --git a/doc/user_docs/misc_intel.rst b/doc/user_docs/misc_intel.rst new file mode 100644 index 0000000..dca535e --- /dev/null +++ b/doc/user_docs/misc_intel.rst @@ -0,0 +1,205 @@ +======================== +Miscellaneous Intel info +======================== + +BBAR on ICH8 +============ + +There is no sign of BBAR (BIOS Base Address Configuration Register) in the +public datasheet (or specification update) of the ICH8. Also, the offset of +that register has changed between ICH7 (SPIBAR + 50h) and ICH9 (SPIBAR + +A0h), so we have no clue if or where it is on ICH8. Out current policy is to +not touch it at all and assume/hope it is 0. + +Software Sequencing vs. Hardware Sequencing and the "Opaque flash chip" +======================================================================= + +Software sequencing and hardware sequencing are two methods used to interface +with the SPI controller on Intel platforms. They can be selected using either +ich_spi_mode=swseq or ich_spi_mode=hwseq programmer parameters. Flashrom will +attempt to automatically detect which mode to use. + +Software sequencing is the traditional method whereby software running on the +CPU handles most of the logic needed to interact with the flash chip. This +offers good flexibility since the user can utilize any opcode available in the +OPMENU registers, and OPMENU can be left unlocked or on coreboot-supported +platforms the owner of the system may program it for their needs before locking +it. Advanced or non-standard features of a chip such as write protection and +OTP may therefore be directly utilized by software. + +Hardware sequencing is a newer method (since around 2011) whereby most of the +logic for interacting with the SPI flash chip is contained within the SPI +controller itself and software such as flashrom may only select a few operations +chosen by Intel via the Flash Cycle (FCYCLE) field. The chip must conform to +specifications from Intel for each chipset/PCH. The specs are given in the +"SPI Programming Guide" application note. See [SPI_PROG] cited at the bottom of +this document for an example. + +Hardware sequencing simplifies things from a software perspective since the +software is guaranteed some minimal level of support and doesn't even need to +know the chip's ID or opcodes; it just needs to tell the SPI controller to +perform a type of transaction such as "read", "4k block erase", etc. Hence when +using hardware sequencing one will see "Opaque flash chip" as the chip's +description since software might not be able to identify the chip. The SPI +controller can combine multiple physical flash chips to logically appear as a +single large flash device, and in such cases it would not make sense for +flashrom to try to identify the chip. + +In many non-Intel systems the software has full control of a generic SPI +controller where the software controls the SPI signals and also constructs the +data payload including pre-op (e.g. write enable latch), opcode, address, and +data. Intel SPI flash controllers are purpose-built for flash chip access and +the software does not control the hardware directly. This makes Intel SPI +controllers less flexible from a software standpoint, however there are some +benefits such as guaranteed atomicity and multi-master arbitration needed for +modern Intel platforms where the CPU and various microprocessors can share the +same flash chip. + +SMM BIOS Write Protection +========================= + +Sometimes a hardware vendor will enable "SMM BIOS Write Protect" (SMM_BWP) +in the firmware during boot time. The bits that control SMM_BWP are in the +BIOS_CNTL register in the LPC interface. + +When enabled, the SPI flash can only be written when the system is operating in +in System Management Mode (SMM). In other words, only certain code that was +installed by the BIOS can write to the flash chip. Programs that run in OS +context such as flashrom can still read the flash chip, but cannot write to the +flash chip. + +Flashrom will attempt to detect this and print a warning such as the following: +"Warning: BIOS region SMM protection is enabled!" + +Many vendor-supplied firmware update utilities do not actually write to the ROM; +instead they transfer data to/from memory which is read/written by a routine +running in SMM and is responsible for writing to the firmware ROM. This causes +severe system performance degradataion since all processors must be in SMM +context (ring -2) instead of OS context (ring 0) while the firmware ROM is being +written. + +Accesses beyond region bounds in descriptor mode +================================================ + +Intel's flash image tool will always expand the last region so that it covers +the whole flash chip, but some boards ship with a different configuration. +It seems that in descriptor mode all addresses outside the used regions can not +be accessed whatsoever. This is not specified anywhere publicly as far as we +could tell. flashrom does not handle this explicitly yet. It will just fail +when trying to touch an address outside of any region. +See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html + +(Un)locking the ME region +========================= + +If the ME region is locked by the FRAP register in descriptor mode, the host +software is not allowed to read or write any address inside that region. +Although the chipset datasheets specify that "[t]he contents of this register +are that of the Flash Descriptor" [PANTHER], this is not entirely true. +The firmware has to fill at least some of the registers involved. It is not +known when they become read-only or any other details, but there is at least +one HM67-based board, that provides an user-changeable setting in the firmware +user interface to enable ME region updates that lead to a FRAP content that is +not equal to the descriptor region bits [NC9B]. + +There are different ways to unlock access: + + * A pin strap: Flash Descriptor Security Override Strap (as indicated by the + Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is + probably not accessible to end users on consumer boards (every Intel doc i + have seen stresses that this is for debugging in manufacturing only and + should not be available for end users). + The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of + the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL]. + + * Intel Management Engine BIOS Extension (MEBx) Disable + This option may be available to end users on some boards usually accessible + by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not + really disable it: it causes the Intel ME code to be halted at an early stage + of the Intel ME's booting so that the system has no traffic originating from + the Intel ME on any of the buses." [MEBX] The ME indicates this in + bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device + by setting them to 3 (Soft Temporary Disable) [MODE_CTRL]. + + * Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or + channel?) #0 disables the ME completely, which may give the host access to + the ME region. + + * HMRFPO (Host ME Region Flash Protection Override) Enable MEI command + This is the most interesting one because it allows to temporarily disable + the ME region protection by software. The ME indicates this in bits [19:16] + (Operation Mode) in the HFS register of the HECI/MEI PCI device by setting + them to 5 (SECOVER_MEI_MSG) [MODE_CTRL]. + +MEI/HECI +======== + +Communication between the host software and the different services provided by +the ME is done via a packet-based protocol that uses MMIO transfers to one or +more virtual PCI devices. Upon this layer there exist various services that can +be used to read out hardware management values (e.g. temperatures, fan speeds +etc.). The lower levels of that protocol are well documented: +The locations/offsets of the PCI MMIO registers are noted in the chipset +datasheets. The actually communication is documented in a whitepaper [DCMI] and +an outdated as well as a current Linux kernel implementation (currently in +staging/ exist [KERNEL]. There exists a patch that re-implements this in user +space (as part of flashrom). + +Problems +======== + +The problem is that only very few higher level protocols are documented publicly, +especially the bunch of messages that contain the HMRFPO commands is probably +well protected and only documented in ME-specific docs and the BIOS writer's +guides. We are aware of a few leaked documents though that give us a few hints +about it, but nothing substantial regarding its implementation. + +The documents are somewhat contradicting each other in various points which +might be due to factual changes in process of time or due to the different +capabilities of the ME firmwares, example: + +Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI +ME Region, to prevent both writing at the same time, causing data corruption." [ME8] + +"FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if +used to update the ME Region." [SPS] + +When looking at the various ME firmware editions (and different chipsets), things +get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST +(EOP), others say that the ME region can be updated in the field or that some +vendor tools use it for updates. This needs to be investigated further before +drawing any conclusion. + +[PANTHER] + Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet + Document Number: 326776, April 2012, page 857 + +[NC9B] + Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked. + NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b". + http://paste.flashrom.org/view.php?id=1215 + +[MODE_CTRL] + Client Platform Enabling Tour: Platform Software + Document Number: 439167, Revision 1.2, page 52 + +[MEBX] + Intel Management Engine BIOS Extension (MEBX) User's Guide + Revision 1.2, Section 3.1 and 3.5 + +[DCMI] + DCMI Host Interface Specification + Revision 1.0 + +[SPI_PROG] + Ibex Peak SPI Programming Guide + Document Number: 403598, Revision 1.3, page 79 + +[ME8] + Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series + Revision 2.0, page 59 + +[SPS] + Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1 + for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware + Revision 2.2, page 51 -- To view, visit https://review.coreboot.org/c/flashrom/+/82649?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I79af5674f3af9ca880e89becd6a272a2cf8ed599 Gerrit-Change-Number: 82649 Gerrit-PatchSet: 1 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org>

1 0

[S] Change in flashrom[main]: doc: Add doc for supported flash chips
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Attention is currently required from: Alexander Goncharov, Thomas Heijligen, Victor Lim. Anastasia Klimchuk has posted comments on this change by Anastasia Klimchuk. ( https://review.coreboot.org/c/flashrom/+/82197?usp=email ) Change subject: doc: Add doc for supported flash chips ...................................................................... Patch Set 3: (3 comments) File doc/supported_hw/supported_flashchips.rst: https://review.coreboot.org/c/flashrom/+/82197/comment/df9bde28_7255d088?us… : PS2, Line 12: Alternatively inspect the file on the `web UI of our GitHub mirror <https://github.com/flashrom/flashrom/blob/main/flashchips.c>`_. > I would suggest moving this paragraph to the first one, because they're logically related Done https://review.coreboot.org/c/flashrom/+/82197/comment/09fba9c5_1f8a2639?us… : PS2, Line 14: If you want to check whether a flash chip is supported in the given release, you can rebase your local : repo at the release tag, alternatively select a tag/branch in GitHub web UI (dropdown on the top-left). > It doesn't sound like a really user-friendly method to check whether a desired flash chip is support […] I don't want to have *another* list of supported chips, I think there should be one canonical list in flashchips.c and then we can avoid duplication also not need to synchronize. But! I was thinking maybe we can have a clever code/script which loops through flashchips.c and generates .rst file. And then sphinx would generate html file from it as a part of building docs. This would be cool, but I haven't looked into details how to do this :) I also don't think this version is final , I just wanted to start the page. It's easier to update the page which exists (and perhaps other people will help). Even after print_wiki.c deleted (which I plan to do only after the release), there will still be still print.c which is doing basically the same just without html tags! Also yes, please add to the agenda any time :) Let me know what do you think whether this patch can go ahead. https://review.coreboot.org/c/flashrom/+/82197/comment/b180fc9f_d1f6378d?us… : PS2, Line 23: Instructions how to update tested status of the chip are here: :doc:`/contrib_howtos/how_to_mark_chip_tested`. : : Instructions how to add support for a chip are here: :doc:`/contrib_howtos/how_to_add_new_chip`. > How about just adding them as a "related topics" list? Done -- To view, visit https://review.coreboot.org/c/flashrom/+/82197?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I05fb60a4caf2cfb30586fa482687b10638996395 Gerrit-Change-Number: 82197 Gerrit-PatchSet: 3 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: Victor Lim <vlim(a)gigadevice.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Victor Lim <vlim(a)gigadevice.com> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de> Gerrit-Attention: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Comment-Date: Sat, 25 May 2024 10:26:23 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Alexander Goncharov <chat(a)joursoir.net>

1 0

[XS] Change in flashrom[main]: doc: Link useful section of manpage into Supported programmers index
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Attention is currently required from: Thomas Heijligen. Anastasia Klimchuk has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/82646?usp=email ) Change subject: doc: Link useful section of manpage into Supported programmers index ...................................................................... doc: Link useful section of manpage into Supported programmers index Change-Id: I0c8a761626784f31a71a47c2cebff2579ebbe416 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> --- M doc/classic_cli_manpage.rst M doc/supported_hw/supported_prog/index.rst 2 files changed, 3 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/46/82646/1 diff --git a/doc/classic_cli_manpage.rst b/doc/classic_cli_manpage.rst index beafd82..19c804a 100644 --- a/doc/classic_cli_manpage.rst +++ b/doc/classic_cli_manpage.rst @@ -329,6 +329,7 @@ **-R, --version** Show version information and exit. +.. _programmer-specific information: PROGRAMMER-SPECIFIC INFORMATION ------------------------------- diff --git a/doc/supported_hw/supported_prog/index.rst b/doc/supported_hw/supported_prog/index.rst index 3f05c25..130ac20 100644 --- a/doc/supported_hw/supported_prog/index.rst +++ b/doc/supported_hw/supported_prog/index.rst @@ -4,6 +4,8 @@ flashrom supports many different programmers, for the full list you can look into `programmer_table.c <https://github.com/flashrom/flashrom/blob/main/programmer_table.c>`_ in the source tree. Some of the programmers have their own documentation pages, see below. +Please check the :ref:`programmer-specific information` section of the :doc:`/classic_cli_manpage` for more details about programmers and their usage. + If you can run flashrom locally, the command ``flashrom -L`` prints all devices supported per programmer (see :doc:`/classic_cli_manpage` for more details on command line options). The output of this command is long, so you might want to save it to file or grep. -- To view, visit https://review.coreboot.org/c/flashrom/+/82646?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I0c8a761626784f31a71a47c2cebff2579ebbe416 Gerrit-Change-Number: 82646 Gerrit-PatchSet: 1 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de>

1 0

[S] Change in flashrom[main]: doc: Add doc for supported flash chips
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Attention is currently required from: Anastasia Klimchuk, Thomas Heijligen, Victor Lim. Hello Alexander Goncharov, Peter Marheine, Thomas Heijligen, Victor Lim, build bot (Jenkins), I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/flashrom/+/82197?usp=email to look at the new patch set (#3). The following approvals got outdated and were removed: Verified+1 by build bot (Jenkins) Change subject: doc: Add doc for supported flash chips ...................................................................... doc: Add doc for supported flash chips Change-Id: I05fb60a4caf2cfb30586fa482687b10638996395 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> --- M doc/supported_hw/index.rst A doc/supported_hw/supported_flashchips.rst 2 files changed, 27 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/97/82197/3 -- To view, visit https://review.coreboot.org/c/flashrom/+/82197?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I05fb60a4caf2cfb30586fa482687b10638996395 Gerrit-Change-Number: 82197 Gerrit-PatchSet: 3 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: Victor Lim <vlim(a)gigadevice.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Victor Lim <vlim(a)gigadevice.com> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org>

1 0

[S] Change in flashrom[main]: flashchips: add support for MX77U51250F chip
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Attention is currently required from: Bora Guvendik, Nikolai Artemiev, Stefan Reinauer. Anastasia Klimchuk has posted comments on this change by Bora Guvendik. ( https://review.coreboot.org/c/flashrom/+/82626?usp=email ) Change subject: flashchips: add support for MX77U51250F chip ...................................................................... Patch Set 3: (1 comment) Patchset: PS3: Bora, thank you for the patch! Could you please give a link to the datasheet for the chip? Also if you could tell which programmer are you using, and maybe you can give logs, for example you can upload them with https://paste.flashrom.org/ Thank you! -- To view, visit https://review.coreboot.org/c/flashrom/+/82626?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I2c2e94f01dc63f60cf636bc6afe1f033e2a6f83c Gerrit-Change-Number: 82626 Gerrit-PatchSet: 3 Gerrit-Owner: Bora Guvendik <bora.guvendik(a)intel.com> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Bora Guvendik <bora.guvendik(a)intel.com> Gerrit-Attention: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Comment-Date: Sat, 25 May 2024 08:56:05 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[S] Change in flashrom[main]: flashchips.c: Add support for XM25RU256C
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Attention is currently required from: Georg Gottleuber, Nikolai Artemiev, Stefan Reinauer. Anastasia Klimchuk has posted comments on this change by Georg Gottleuber. ( https://review.coreboot.org/c/flashrom/+/82101?usp=email ) Change subject: flashchips.c: Add support for XM25RU256C ...................................................................... Patch Set 2: (2 comments) Patchset: PS1: > I have personally asked for the datasheet, but I don't know if it is okay to publish it. […] Sorry for delay in replying, I was thinking about your patch on the background. I usually ask for datasheet to check the values, but after all, you (the contributor) are the person who has the chip and running flashrom on it, so you did the actual testing, not me. The trickiest part of chip definition is write-protect bits, but you are not adding that support anyway. I think we can go ahead with the patch, I only have one small comment about indentation. If you double-check the values with datasheet, that would be really nice! Also if there were some of the fields that you were not entirely sure what to put there, please tell me. Thank you! File flashchips.c: https://review.coreboot.org/c/flashrom/+/82101/comment/c74866a0_214296b7?us… : PS2, Line 21729: | FEATURE_4BA_EAR_C5C8 | FEATURE_4BA_READ | FEATURE_4BA_FAST_READ : | FEATURE_4BA_WRITE, Sorry I didn't notice last time: please intend these two lines so that they align with the first feature line (align with FEATURE_WRSR_WREN). We keep all the values on the right-side of `=` signs, it's easier to read. -- To view, visit https://review.coreboot.org/c/flashrom/+/82101?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I431474a662304d09438e274706d3fc9cfbbe0bd6 Gerrit-Change-Number: 82101 Gerrit-PatchSet: 2 Gerrit-Owner: Georg Gottleuber <ggo(a)tuxedo.de> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Georg Gottleuber <ggo(a)tuxedo.de> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Comment-Date: Sat, 25 May 2024 08:34:17 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Georg Gottleuber <ggo(a)tuxedo.de> Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org>

1 0

[S] Change in flashrom[main]: Add documentation for pico-serprog
by Anastasia Klimchuk (Code Review) 25 May '24

25 May '24

Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/82229?usp=email ) Change subject: Add documentation for pico-serprog ...................................................................... Add documentation for pico-serprog This commit adds documentation for pico-serprog by stacksmashing: https://github.com/stacksmashing/pico-serprog and its fork by Riku_V: https://codeberg.org/Riku_V/pico-serprog to the serprog overview page. Change-Id: I457dfec52f89997f64b6c276c50b329359d61b77 Signed-off-by: Funkeleinhorn <git(a)funkeleinhorn.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82229 Reviewed-by: Anastasia Klimchuk <aklm(a)chromium.org> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M doc/supported_hw/supported_prog/serprog/overview.rst 1 file changed, 12 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Anastasia Klimchuk: Looks good to me, approved diff --git a/doc/supported_hw/supported_prog/serprog/overview.rst b/doc/supported_hw/supported_prog/serprog/overview.rst index b274b99..ba01b02 100644 --- a/doc/supported_hw/supported_prog/serprog/overview.rst +++ b/doc/supported_hw/supported_prog/serprog/overview.rst @@ -81,3 +81,15 @@ A powerful option is `stm32-vserprog <https://github.com/dword1511/stm32-vserprog#stm32-vserprog>`_, a firmware for various STM32-based boards that turns them into serprog-based programmers with SPI clock speeds up to 36 MHz. + +pico-serprog +------------ + +`pico-serprog <https://github.com/stacksmashing/pico-serprog>`_ by stacksmashing is a firmware for +`Raspberry Pi Picos <https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pic…>`_ and other RP2040 based boards which turns them +into a serprog programmer. + +Notable forks are: + +`Riku_V's fork <https://codeberg.org/Riku_V/pico-serprog>`_ which uses the hardware SPI implementation instead of SPI over PIO (programmable IO) which +sacrifices arbitrary pinouts. The fork also implements custom USB descriptors which allow for custom udev-rules. -- To view, visit https://review.coreboot.org/c/flashrom/+/82229?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I457dfec52f89997f64b6c276c50b329359d61b77 Gerrit-Change-Number: 82229 Gerrit-PatchSet: 5 Gerrit-Owner: Sydney <git(a)funkeleinhorn.com> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: J. Neuschäfer <j.neuschaefer(a)gmx.net> Gerrit-Reviewer: Riku Viitanen <riku.viitanen(a)protonmail.com> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[XS] Change in flashrom[main]: flashchips: Correct feature_bits for MX25L128*
by Anastasia Klimchuk (Code Review) 24 May '24

24 May '24

Attention is currently required from: Hsuan Ting Chen, Hsuan-ting Chen, Nikolai Artemiev, Stefan Reinauer. Anastasia Klimchuk has posted comments on this change by Hsuan-ting Chen. ( https://review.coreboot.org/c/flashrom/+/82605?usp=email ) Change subject: flashchips: Correct feature_bits for MX25L128* ...................................................................... Patch Set 1: Code-Review+2 (1 comment) Patchset: PS1: > Update: I checked that with `-p internal` the current ToT will pass `--wp-status`; however, with `-p […] Thank you so much for testing and fixing! So do I understand correctly that now everything works with this patch? -- To view, visit https://review.coreboot.org/c/flashrom/+/82605?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I001cde6816bd099317bc9c23904c5fcbe6003241 Gerrit-Change-Number: 82605 Gerrit-PatchSet: 1 Gerrit-Owner: Hsuan-ting Chen <roccochen(a)google.com> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Hsuan Ting Chen <roccochen(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Hsuan Ting Chen <roccochen(a)chromium.org> Gerrit-Attention: Hsuan-ting Chen <roccochen(a)google.com> Gerrit-Attention: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Comment-Date: Fri, 24 May 2024 14:50:41 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: Hsuan-ting Chen <roccochen(a)google.com>

1 0

[L] Change in flashrom[main]: erasure_layout: Fix get_flash_region bug
by Anastasia Klimchuk (Code Review) 24 May '24

24 May '24

Attention is currently required from: Aarya, Alexander Goncharov, Nikolai Artemiev, Peter Marheine. Anastasia Klimchuk has posted comments on this change by Peter Marheine. ( https://review.coreboot.org/c/flashrom/+/82393?usp=email ) Change subject: erasure_layout: Fix get_flash_region bug ...................................................................... Patch Set 9: (12 comments) Patchset: PS9: Thank you so much for combining all the work in one patch! File erasure_layout.c: https://review.coreboot.org/c/flashrom/+/82393/comment/6c9f690b_7d0b2429?us… : PS5, Line 240: > I'm a little hesitant to, because `chipoff_t` implies inclusive endpoints. […] I forgot that `chipoff_t` has its own comment. Now I agree with you. https://review.coreboot.org/c/flashrom/+/82393/comment/efeaeea0_4087bd38?us… : PS5, Line 369: len = min(region_end, region.end - 1) - addr + 1; > I added a new parent change that fixes get_flash_region's incorrect use of chipoff_t (now the upper […] This is great, thank you! File tests/erase_func_algo.c: https://review.coreboot.org/c/flashrom/+/82393/comment/ec18619d_d61c83fa?us… : PS9, Line 766: 16 To be consistent with your previous patch, and also I think tests are partially a documentation (a special kind of it), this needs to be 15, right? https://review.coreboot.org/c/flashrom/+/82393/comment/d03af7c3_02c698ba?us… : PS9, Line 951: get_erase_protected_region_algo_tests I think these ones can be also run through write operation, and verifying the memory state after write. The change in flashrom.c affects write as well. But this can be in a separate patch. https://review.coreboot.org/c/flashrom/+/82393/comment/e4e82405_a99070ef?us… : PS9, Line 953: const size_t num_unparameterized = 1; Do you think this is needed? It's the same name and the same function. If you change it to 2, it will run the same test twice. Maybe remove this and allocate one test? https://review.coreboot.org/c/flashrom/+/82393/comment/d42614b2_b3d5edc6?us… : PS9, Line 973: .name = "erase failure for unskipped unwritable regions", I had the trouble with test names, because I wanted an index (a test case #) in the name. This one is just one, so a name without an index is fine. I looked into the test `test_erase_fails_for_unwritable_region` I think it's only flag FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS that prevents in from being in the list? setup and teardown seem innocent, won't hurt to have them here. So it's not being unparameterized , but FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS=false is what makes this test different? Anyway, this can be changed later. https://review.coreboot.org/c/flashrom/+/82393/comment/80c8e648_8638f708?us… : PS9, Line 1103: 16 This is `END_PROTECTED_REGION + 1`, just for perfection (with my other comment about END_PROTECTED_REGION) https://review.coreboot.org/c/flashrom/+/82393/comment/7d1ee9a4_154eadc2?us… : PS9, Line 1138: < <= if you agree that it should be inclusive https://review.coreboot.org/c/flashrom/+/82393/comment/8c05f3fd_11e1d2f6?us… : PS9, Line 1140: < also here <= File tests/tests.h: https://review.coreboot.org/c/flashrom/+/82393/comment/310596a6_375a8f10?us… : PS9, Line 113: void erase_unwritable_regions_skipflag_off_test_success(void **state); this also can be removed from this patch https://review.coreboot.org/c/flashrom/+/82393/comment/f5a48954_05c164c1?us… : PS9, Line 114: erase_unwritable_regions_skipflag_on_test_success I am wondering maybe this is also not needed. Because the function which is called in tests.c is `get_erase_func_algo_tests` but not this one. I added this line, but then also tests ended up having a special invocation and I think it's not needed anymore. -- To view, visit https://review.coreboot.org/c/flashrom/+/82393?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ic5bf9d0f0e4a94c48d6f6e74e3cb9cccdc7adec9 Gerrit-Change-Number: 82393 Gerrit-PatchSet: 9 Gerrit-Owner: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Attention: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Comment-Date: Fri, 24 May 2024 14:36:36 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Peter Marheine <pmarheine(a)chromium.org>

1 0

[S] Change in flashrom[main]: Correct get_flash_region() to use inclusive upper bounds
by Anastasia Klimchuk (Code Review) 24 May '24

24 May '24

Attention is currently required from: Aarya, Nikolai Artemiev, Peter Marheine. Anastasia Klimchuk has posted comments on this change by Peter Marheine. ( https://review.coreboot.org/c/flashrom/+/82496?usp=email ) Change subject: Correct get_flash_region() to use inclusive upper bounds ...................................................................... Patch Set 2: (4 comments) Patchset: PS2: Thank you for fixing old tech debt ! File flashrom.c: https://review.coreboot.org/c/flashrom/+/82496/comment/772c9434_a3c6054d?us… : PS2, Line 1518: region.end - 1 `region.end` like in everywhere else? https://review.coreboot.org/c/flashrom/+/82496/comment/d494ed4d_802c4ab2?us… : PS2, Line 1524: region.end - 1 also `region.end` ? File ichspi.c: https://review.coreboot.org/c/flashrom/+/82496/comment/d5160f98_f0187702?us… : PS2, Line 1454: limit Why you are changing this? I understand why region end changes, but why region start? Is this another bug? -- To view, visit https://review.coreboot.org/c/flashrom/+/82496?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ia0ca867aef33b598c2697fc264807fa5e29683ec Gerrit-Change-Number: 82496 Gerrit-PatchSet: 2 Gerrit-Owner: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Comment-Date: Fri, 24 May 2024 09:54:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

2024

2023

2022

2021

2020

2019

2018

2017

flashrom-gerrit May 2024