- flashrom-gerrit - mail.coreboot.org

[S] Change in flashrom[main]: flashchips: Add support for PUYA P25Q40H
by Anne "Anya" Macedo (Code Review) 03 Oct '23

03 Oct '23

Attention is currently required from: Anastasia Klimchuk. Anne "Anya" Macedo has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/76251?usp=email ) Change subject: flashchips: Add support for PUYA P25Q40H ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > Anne, just wanted to ask how are you doing, do you think you can get back to your patch and fix the […] Hello! My apologies, life came in the way the last few months. Please go ahead with your patch! I don't have my lab up and running right now so I won't be able to work on that soon. -- To view, visit https://review.coreboot.org/c/flashrom/+/76251?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I58c2c0467ef19f98b7435e84b6978550f029af70 Gerrit-Change-Number: 76251 Gerrit-PatchSet: 1 Gerrit-Owner: Anne "Anya" Macedo <retpolanne(a)posteo.net> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Comment-Date: Tue, 03 Oct 2023 15:52:09 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Anne "Anya" Macedo <retpolanne(a)posteo.net> Gerrit-MessageType: comment

1 0

[L] Change in flashrom[main]: doc: Convert write-protect docs to sphinx
by Anastasia Klimchuk (Code Review) 01 Oct '23

01 Oct '23

Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/78113?usp=email ) Change subject: doc: Convert write-protect docs to sphinx ...................................................................... doc: Convert write-protect docs to sphinx Updated the information that WP is included in the v1.3 release, and added links to dev guidelines on how to build from head (instead of inlining the instructions). Change-Id: I223f1aa5f4531b28b04bcfcecd9becfa7899c3d9 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/78113 Reviewed-by: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M doc/index.rst A doc/user_docs/example_partial_wp.rst A doc/user_docs/fw_updates_vs_spi_wp.rst A doc/user_docs/index.rst 4 files changed, 260 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Sergii Dmytruk: Looks good to me, approved diff --git a/doc/index.rst b/doc/index.rst index 1943934..3a303e1 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -10,6 +10,7 @@ :hidden: dev_guide/index + user_docs/index classic_cli_manpage contact about_flashrom/index diff --git a/doc/user_docs/example_partial_wp.rst b/doc/user_docs/example_partial_wp.rst new file mode 100644 index 0000000..67a382a --- /dev/null +++ b/doc/user_docs/example_partial_wp.rst @@ -0,0 +1,191 @@ +=================================== +Example of partial write-protection +=================================== + +This document provides demonstration of how one can protect part of a flash chip +from writing using :code:`flashrom` and its support for manipulating SPI write protection (WP). +This kind of protection requires changing connection of WP pin of the chip to prevent +any attempt of disabling the protection by software alone. + +Not to be confused with protection by flash controller of your motherboard (PCH protection). + +Version of flashrom +=================== + +Write-protect manipulation functionality is included in flashrom since release v1.3.0. +If for any reasons you need the latest code from head, you might need to build :code:`flashrom` +from scratch. The following docs describe how to do this :doc:`/dev_guide/building_from_source` and +:doc:`/dev_guide/building_with_make`. See also :doc:`/dev_guide/development_guide`. + +Alternatively, your operating system might provide development version of :code:`flashrom` as a package. + +Programmer support of WP +======================== + +Not all programmers support manipulating WP configuration. A suitable programmer must either +provide a dedicated API for working with WP or give sufficiently comprehensive access to the +interface of the flash chip. + +In particular, *internal* programmer on Intel platforms might allow only limited access to WP +feature of chips or effectively deny it. Read "Intel chipsets" section of flashrom's manpage +for details on how you can try choosing sequencing type to possibly make WP work for you. + +In some cases external flashing might be the only option and you need to unscrew your device, +find the chip, connect it to another device through a suitable adapter and finally be able +to configure it as you wish. + +Chip support in flashrom +======================== + +There is a great variety of chips with some not supporting write protection at all and others +doing it in their own peculiar way of which :code:`flashrom` has no idea. So the first thing to do is +to make sure that :code:`flashrom` knows how WP works for your chip and chipset doesn't get in the way. +Run a command like (adjust this and similar commands below if you're not using *internal* programmer +or need to specify other options):: + + flashrom --programmer internal --wp-status: + +Seeing this output line would mean that :code:`flashrom` doesn't know how to use WP feature of the chip you have:: + + Failed to get WP status: WP operations are not implemented for this chip + +Otherwise the output might contain something similar to this:: + + Protection range: start=0x00000000 length=0x00000000 (none) + Protection mode: disabled + +If so, you can continue with the rest of the instructions. + +Collecting information about the range +====================================== + +You need to know where the area you want to protect starts and ends. The example below assumes +you're trying to protect bootblock stored in CBFS at the end of some :code:`coreboot` firmware. In other cases +it might be a separate file which is put at the beginning of a chip. You need to have an idea of what +you're doing here or have some reliable instructions to follow. + +In this case :code:`cbfstool` can be used to list information about bootblock like this:: + + $ cbfstool rom print | sed -n '2p; /bootblock/p' + Name Offset Type Size Comp + bootblock 0x3ef100 bootblock 36544 none + +However, the offset is relative to the start of CBFS region, so we also need to find out offset of CBFS:: + + $ cbfstool rom layout | grep CBFS + 'COREBOOT' (CBFS, size 4161536, offset 12615680) + +Now we can calculate: + +* start offset (CBFS offset + 64 + bootblock offset):: + + 12615680 + 64 + 0x3ef100 = 0xff7140 + (printf "%#x\n" $(( 12615680 + 64 + 0x3ef100 ))) + +* end offset (start offset + bootblock size - 1):: + + 0xff7140 + 36544 - 1 = 0xffffff + (printf "%#x\n" $(( 0xff7140 + 36544 - 1 ))) + +Thus we need to write-protect the smallest area that covers the range from :code:`0xff7140` to :code:`0xffffff` +(both bounds are inclusive). + +“64” in the computation of start offset is offset of booblock data. Unfortunately, current tooling +doesn't provide a reliable way of determining actual offset, but 64 is the typical “extra offset” one needs +to add to account for file metadata of CBFS (otherwise it can be its multiple 128 or bigger). Bootblock +should normally end at the last byte of ROM on x86 systems, giving you a way to test the result of computations. + +Finding a matching range +======================== + +In most chips the list of supported ranges is fixed and you can't specify an arbitrary one. Some others +allow more fine-grained control (sector/block-based), but that feature is not supported even by development +version of flashrom at the time of writing (September 2023). + +Obtain list of supported ranges from which we'll pick the best match:: + + $ flashrom --programmer internal --wp-list + ... + Available protection ranges: + start=0x00000000 length=0x00000000 (none) + start=0x00000000 length=0x00001000 (lower 1/4096) + start=0x00fff000 length=0x00001000 (upper 1/4096) + start=0x00000000 length=0x00002000 (lower 1/2048) + start=0x00ffe000 length=0x00002000 (upper 1/2048) + start=0x00000000 length=0x00004000 (lower 1/1024) + start=0x00ffc000 length=0x00004000 (upper 1/1024) + start=0x00000000 length=0x00008000 (lower 1/512) + start=0x00ff8000 length=0x00008000 (upper 1/512) + start=0x00000000 length=0x00040000 (lower 1/64) + start=0x00fc0000 length=0x00040000 (upper 1/64) + start=0x00000000 length=0x00080000 (lower 1/32) + start=0x00f80000 length=0x00080000 (upper 1/32) + start=0x00000000 length=0x00100000 (lower 1/16) + start=0x00f00000 length=0x00100000 (upper 1/16) + start=0x00000000 length=0x00200000 (lower 1/8) + start=0x00e00000 length=0x00200000 (upper 1/8) + start=0x00000000 length=0x00400000 (lower 1/4) + start=0x00c00000 length=0x00400000 (upper 1/4) + start=0x00000000 length=0x00800000 (lower 1/2) + start=0x00800000 length=0x00800000 (upper 1/2) + start=0x00000000 length=0x00c00000 (lower 3/4) + start=0x00400000 length=0x00c00000 (upper 3/4) + start=0x00000000 length=0x00e00000 (lower 7/8) + start=0x00200000 length=0x00e00000 (upper 7/8) + start=0x00000000 length=0x00f00000 (lower 15/16) + start=0x00100000 length=0x00f00000 (upper 15/16) + start=0x00000000 length=0x00f80000 (lower 31/32) + start=0x00080000 length=0x00f80000 (upper 31/32) + start=0x00000000 length=0x00fc0000 (lower 63/64) + start=0x00040000 length=0x00fc0000 (upper 63/64) + start=0x00000000 length=0x00ff8000 (lower 511/512) + start=0x00008000 length=0x00ff8000 (upper 511/512) + start=0x00000000 length=0x00ffc000 (lower 1023/1024) + start=0x00004000 length=0x00ffc000 (upper 1023/1024) + start=0x00000000 length=0x00ffe000 (lower 2047/2048) + start=0x00002000 length=0x00ffe000 (upper 2047/2048) + start=0x00000000 length=0x00fff000 (lower 4095/4096) + start=0x00001000 length=0x00fff000 (upper 4095/4096) + start=0x00000000 length=0x01000000 (all) + +Pick a range by scanning the list in the top down order (because the smaller ranges come first): + + * if bootblock is at the start of a chip, look for the first lower range whose length is greater than the end offset + * if bootblock is at the end of a chip, look for the first upper range which starts before or at the start offset + * mind that you're unlikely to find an ideal match and will probably protect more than you need; this is fine + if that's just an empty space, but can cause trouble with future updates if that's some data or metadata which + changes with every release (see :doc:`fw_updates_vs_spi_wp` for more on this) + +This is the first upper range starting before 0xff7140:: + + start=0x00fc0000 length=0x00040000 (upper 1/64) + +It covers :code:`0x00fc0000 - 0x00ffffff` which includes our bootblock. This area takes up 256 KiB, about 7 times bigger +than our bootblock, but there is no better choice in this case and output of :code:`cbfstool rom layout` shows +that we additionally include a part of 876 KiB empty space which will hopefully remain there in future firmware versions +(it's a good idea to check before a firmware update). + +Protection setup +================ + +The following command sets the range and enables WP at the same time, the values are taken from the chosen range above:: + + flashrom --programmer internal --wp-range=0x00fc0000,0x00040000 --wp-enable + +You can set the range and change WP status independently as well if needed (just specify one :code:`--wp-*` option at a time). +Make sure that hardware protection is off (state of :code:`W#`/:code:`W/` pin of the chip) or you won't be able +to change WP configuration. + +On success, the output of the above command will include such lines:: + + Enabled hardware protection + Activated protection range: start=0x00fc0000 length=0x00040000 (upper 1/64) + +**Caveat:** :code:`flashrom` automatically tries to disable WP before any operation on a chip (read, write, erase, verify), +so double-check status of WP before changing state of WP pin on your chip! + +Verifying hardware protection +============================= + +Once you're happy with the configuration and changed state of WP pin, you can try disabling WP +using :code:`flashrom --wp-disable` to make sure that it fails now. diff --git a/doc/user_docs/fw_updates_vs_spi_wp.rst b/doc/user_docs/fw_updates_vs_spi_wp.rst new file mode 100644 index 0000000..43bcbe0 --- /dev/null +++ b/doc/user_docs/fw_updates_vs_spi_wp.rst @@ -0,0 +1,60 @@ +======================================== +Firmware updates vs SPI write-protection +======================================== + +Enabling write-protection of any kind is meant to obstruct changing data, but it also limits +what you can do to the part of firmware that's still writable. This document is meant to cover +some of the origins of such limitations and situations which might arise after +part of a flash chip has been protected. + +Firmware updates after locking bootblock +======================================== + +This section is primarily concerned with :code:`coreboot` with bootblock being protected from writing, +but similar problems can happen for any kind of firmware. + +Risks of partial updates +------------------------ + +Partial updates can produce an unbootable image if an old bootblock doesn't work with a more recent +version of :code:`coreboot`. This can be manifested in various ways ranging from an old bootblock not being able +to find new romstage to system booting successfully but data in :code:`coreboot` tables being mangled or incomplete. + +The incompatibilities might happen when switching version of firmware or even when using the same version +with a slightly different configuration. + +Another thing that can potentially cause trouble is CBFS layout. When bootblock is part of CBFS, +it doesn't necessarily have a fixed address, moreover it can change location as well if it depends on file size +(when bootblock's last byte must be the last byte of the image, which is the case on x86). If newer bootblock +is smaller such that an old WP range now covers bootblock and some other file, this file won't be fully updated +due to write-protection, potentially resulting in a corrupt image. Luckily, when bootblock is the last file +it's normally preceded by a significant amount of empty space, which won't let this situation to occur. + +On top of that, last 4 bytes of the image contain offset to the master header of CBFS. Depending on +the :code:`coreboot` version this offset might be crucial for the loading of romstage, in which case moving CBFS +within the image without updating the offset (when it's locked by WP) can also prevent the system from booting. + +Recovering from a broken state +------------------------------ + +Since broken flash won't let the system to boot, the way to fix it is to flash the chip externally by connecting +it to a different device. A possible alternative could be to have a backup flash created beforehand and swapping +it for the broken one (not very applicable if swapping doesn't require soldering). There are also some mainboards +with dual flash chips one of which acts as a backup that can be restored by holding power on button long enough. + +Flashing whole firmware image +============================= + +The function of the hardware protection mechanism (:code:`W#` or :code:`W/` pin of flash chips) is to lock state of +software protection thus preventing it from being disabled. After the chip is physically unlocked by changing +the state of the pin, the state of the write protection doesn't change. However, in this state the protection +can be easily turned off programmatically, which is what :code:`flashrom` tries to do before performing an operation on a chip. + +In other words, changing state of the WP pin might be enough to be able to flash the chip in full. +If :code:`flashrom` errors or you don't want to rely on the automatic behaviour, you can try to +explicitly disable the protection by running :code:`flashrom` like this:: + + flashrom --wp-disable + +If you need to pass extra parameters to flash your chip (e.g., programmer or chip name), add them to the above command +(order of such parameters shouldn't matter). diff --git a/doc/user_docs/index.rst b/doc/user_docs/index.rst new file mode 100644 index 0000000..b4cca34 --- /dev/null +++ b/doc/user_docs/index.rst @@ -0,0 +1,8 @@ +Users documentation +=================== + +.. toctree:: + :maxdepth: 1 + + fw_updates_vs_spi_wp + example_partial_wp -- To view, visit https://review.coreboot.org/c/flashrom/+/78113?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I223f1aa5f4531b28b04bcfcecd9becfa7899c3d9 Gerrit-Change-Number: 78113 Gerrit-PatchSet: 3 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[S] Change in flashrom[main]: flashchips: Add support for PUYA P25Q40H
by Anastasia Klimchuk (Code Review) 01 Oct '23

01 Oct '23

Attention is currently required from: Anne Macedo. Anastasia Klimchuk has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/76251?usp=email ) Change subject: flashchips: Add support for PUYA P25Q40H ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > Thanks for the review! I'll make the changes as soon as I can. Anne, just wanted to ask how are you doing, do you think you can get back to your patch and fix the comments? :) If you need any help, you can ask questions! I am asking because there is another patch adding Puya chip CB:58134, but that is a very old patch and it seems that contributor had left already. Most likely that I will be finishing CB:58134 myself. I can wait for you and do that other patch after yours, or I can do that other one first, and then you will rebase your on the top. What do you think? -- To view, visit https://review.coreboot.org/c/flashrom/+/76251?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I58c2c0467ef19f98b7435e84b6978550f029af70 Gerrit-Change-Number: 76251 Gerrit-PatchSet: 1 Gerrit-Owner: Anne Macedo <retpolanne(a)posteo.net> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Anne Macedo <retpolanne(a)posteo.net> Gerrit-Comment-Date: Sun, 01 Oct 2023 09:51:43 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Anne Macedo <retpolanne(a)posteo.net> Gerrit-MessageType: comment

1 0

[XS] Change in flashrom[main]: doc: Fix formatting for the example of commit message
by Anastasia Klimchuk (Code Review) 01 Oct '23

01 Oct '23

Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/78120?usp=email ) Change subject: doc: Fix formatting for the example of commit message ...................................................................... doc: Fix formatting for the example of commit message Example of commit message was formatted with code-block directive which has language argument required or optional depending on the sphinx version. Replace code-block with simpler literal block which never has arguments, and also since the text formatted is not actually a code. Change-Id: If0bc8327e973d9bc9a93eea38c83bfab412fb8f4 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/78120 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Patrick Georgi <patrick(a)coreboot.org> Reviewed-by: Alexander Goncharov <chat(a)joursoir.net> --- M doc/dev_guide/development_guide.rst 1 file changed, 1 insertion(+), 3 deletions(-) Approvals: Patrick Georgi: Looks good to me, but someone else must approve Alexander Goncharov: Looks good to me, approved build bot (Jenkins): Verified diff --git a/doc/dev_guide/development_guide.rst b/doc/dev_guide/development_guide.rst index bdbee37..60c5625 100644 --- a/doc/dev_guide/development_guide.rst +++ b/doc/dev_guide/development_guide.rst @@ -51,9 +51,7 @@ Commit message -------------- -Commit messages shall have the following format: - -.. code-block:: +Commit messages shall have the following format:: <component>: Short description (up to 72 characters) -- To view, visit https://review.coreboot.org/c/flashrom/+/78120?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: If0bc8327e973d9bc9a93eea38c83bfab412fb8f4 Gerrit-Change-Number: 78120 Gerrit-PatchSet: 2 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Patrick Georgi <patrick(a)coreboot.org> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[M] Change in flashrom[main]: doc: Add first version of code of conduct
by Stefan Reinauer (Code Review) 30 Sep '23

30 Sep '23

Attention is currently required from: Anastasia Klimchuk, Thomas Heijligen. Stefan Reinauer has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/78203?usp=email ) Change subject: doc: Add first version of code of conduct ...................................................................... Patch Set 2: Code-Review+2 -- To view, visit https://review.coreboot.org/c/flashrom/+/78203?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426 Gerrit-Change-Number: 78203 Gerrit-PatchSet: 2 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Comment-Date: Sat, 30 Sep 2023 14:22:37 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[M] Change in flashrom[main]: doc: Convert release notes for v1.3
by Alexander Goncharov (Code Review) 30 Sep '23

30 Sep '23

Attention is currently required from: Anastasia Klimchuk, Thomas Heijligen. Alexander Goncharov has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/78116?usp=email ) Change subject: doc: Convert release notes for v1.3 ...................................................................... Patch Set 2: Code-Review+2 -- To view, visit https://review.coreboot.org/c/flashrom/+/78116?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I5b66a957249c3025715eff2b00f1be9eb0d36096 Gerrit-Change-Number: 78116 Gerrit-PatchSet: 2 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Comment-Date: Sat, 30 Sep 2023 13:54:53 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[M] Change in flashrom[main]: doc: Add code of conduct
by Anastasia Klimchuk (Code Review) 30 Sep '23

30 Sep '23

Anastasia Klimchuk has abandoned this change. ( https://review.coreboot.org/c/flashrom/+/76455?usp=email ) Change subject: doc: Add code of conduct ...................................................................... Abandoned different approach, see CB:78203 -- To view, visit https://review.coreboot.org/c/flashrom/+/76455?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ic4c646bc47d5db4d064a411d60a44f16559dfcee Gerrit-Change-Number: 76455 Gerrit-PatchSet: 3 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Martin L Roth <gaumless(a)gmail.com> Gerrit-CC: Patrick Georgi <patrick(a)coreboot.org> Gerrit-MessageType: abandon

1 0

[M] Change in flashrom[main]: doc: Add first version of code of conduct
by Anastasia Klimchuk (Code Review) 30 Sep '23

30 Sep '23

Attention is currently required from: Thomas Heijligen. Hello Thomas Heijligen, build bot (Jenkins), I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/flashrom/+/78203?usp=email to look at the new patch set (#2). Change subject: doc: Add first version of code of conduct ...................................................................... doc: Add first version of code of conduct As a starting point, copying coreboot's one in the absence of our own. coreboot's CoC exists for some time and is known to work, so it's a good starting point. We can iterate on this and make upgrades and amendments that make sense for flashrom community. Meanwhile we can share code of conduct with coreboot. We do have the same servers and infrastructure anyway. Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> --- A doc/about_flashrom/code_of_conduct.rst M doc/about_flashrom/index.rst M doc/about_flashrom/team.rst 3 files changed, 144 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/03/78203/2 -- To view, visit https://review.coreboot.org/c/flashrom/+/78203?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426 Gerrit-Change-Number: 78203 Gerrit-PatchSet: 2 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Thomas Heijligen <src(a)posteo.de> Gerrit-MessageType: newpatchset

1 0

[M] Change in flashrom[main]: doc: Add code of conduct
by Anastasia Klimchuk (Code Review) 30 Sep '23

30 Sep '23

Anastasia Klimchuk has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/78203?usp=email ) Change subject: doc: Add code of conduct ...................................................................... doc: Add code of conduct For now link to coreboot's one, in the absence of our own. It is always possible to create our own later, if desired, but meanwhile we can share code of conduct with coreboot. We do have the same servers and infrastructure anyway. Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> --- A doc/about_flashrom/code_of_conduct.rst M doc/about_flashrom/index.rst M doc/about_flashrom/team.rst 3 files changed, 144 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/03/78203/1 diff --git a/doc/about_flashrom/code_of_conduct.rst b/doc/about_flashrom/code_of_conduct.rst new file mode 100644 index 0000000..da94e29 --- /dev/null +++ b/doc/about_flashrom/code_of_conduct.rst @@ -0,0 +1,140 @@ +=============== +Code of Conduct +=============== + +This code of conduct outlines our rules and expectations for everybody +participating in the flashrom community. + +flashrom community etiquette +============================ + +We have a friendly and productive atmosphere on our mailing lists, +development / code review tools, real time chat rooms and when we meet in +person. Our principles evolve around the following: + +* It's not the user's fault if something goes wrong. +* Attempt collaboration before conflict. +* People who intentionally insult others (users, developers, corporations, + other projects, or the flashrom project itself) will be dealt with. See + policy below. +* We are dealing with hardware with lots of undocumented pitfalls. It is quite + possible that you did everything right, but flashrom still won't work for you. + +Refrain from insulting anyone or the group they belong to. Remember that +people might be sensitive to other things than you are. + +Most of our community members are not native English speakers, thus +misunderstandings can (and do) happen. Assume that others are friendly +and may have picked less-than-stellar wording by accident as long as +you possibly can. + +Reporting Issues +================ + +If you have a grievance due to conduct in this community, we're sorry +that you have had a bad experience, and we want to hear about it so +we can resolve the situation. + +Please contact members of our arbitration team (listed below) promptly +and directly, in person (if available) or by email: They will listen +to you and react in a timely fashion. + +If you feel uncomfortable, please don't wait it out, ask for help, +so we can work on setting things right. + +For transparency there is no alias or private mailing list address for +you to reach out to, since we want to make sure that you know who will +and who won't read your message. + +However since people might be on travel or otherwise be unavailable +at times, please reach out to multiple persons at once, especially +when using email. + +The team will treat your messages confidential as far as the law permits. +For the purpose of knowing what law applies, the list provides the usual +country of residence of each team member. + +Unacceptable Behavior +===================== + +Unacceptable behaviors include: intimidating, harassing, abusive, +discriminatory, derogatory or demeaning speech or actions by any +participant in our community online, at all related events and in +one-on-one communications carried out in the context of community +business. Community event venues may be shared with members of the public; +please be respectful to all patrons of these locations. + +Examples of behaviors we do not accept in our community: + +* harmful or prejudicial verbal or written comments related to gender, + sexual orientation, race, religion, disability; +* inappropriate physical contact, and unwelcome sexual advances; +* deliberate intimidation, stalking or following; +* harassing photography or recording; +* sustained disruption of talks or other events. + +Using this code of conduct aggressively against other people in the +community might also be harassment. Be considerate when enforcing the code +of conduct and always try to listen to both sides before passing judgment. + +Consequences of Unacceptable Behavior +===================================== + +Unacceptable behavior from any community member, including sponsors and +those with decision-making authority, will not be tolerated. + +Anyone asked to stop unacceptable behavior is expected to comply +immediately. + +If a community member engages in unacceptable behavior, the community +organizers may take any action they deem appropriate, up to and including +a temporary ban or permanent expulsion from the community without warning +(and without refund in the case of a paid event). + +Community organizers can be members of the arbitration team, or organizers +of events and online communities. + +Addressing Grievances +===================== + +If you feel you have been falsely or unfairly accused of violating this +Code of Conduct, you should notify the arbitration team with a concise +description of your grievance. + +Legal action +============ + +Threatening or starting legal action against the project, sibling +projects hosted on coreboot.org infrastructure, project or infrastructure +maintainers leads to an immediate ban from coreboot.org and related +systems. + +The ban can be reconsidered, but it's the default action because the +people who pour lots of time and money into the projects aren't interested +in seeing their resources used against them. + +Scope +========== + +We expect all community participants (contributors, paid or otherwise; +sponsors; and other guests) to abide by this Code of Conduct in all +community venues, online and in-person, as well as in all one-on-one +communications pertaining to community business. + +Contact info +============ + +Our arbitration team consists of the following people + +* Stefan Reinauer <stefan.reinauer(a)coreboot.org> (USA) +* Patrick Georgi <patrick(a)coreboot.org> (Germany) +* Ronald Minnich <rminnich(a)coreboot.org> (USA) +* Martin Roth <martin(a)coreboot.org> (USA) + +License and attribution +======================= + +This Code of Conduct is distributed under +a `Creative Commons Attribution-ShareAlike +license <http://creativecommons.org/licenses/by-sa/3.0/>`_. It is based +on the `Citizen Code of Conduct <https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/>`_ diff --git a/doc/about_flashrom/index.rst b/doc/about_flashrom/index.rst index de36fc2..49c9849 100644 --- a/doc/about_flashrom/index.rst +++ b/doc/about_flashrom/index.rst @@ -5,3 +5,4 @@ :maxdepth: 1 team + code_of_conduct diff --git a/doc/about_flashrom/team.rst b/doc/about_flashrom/team.rst index 9d002bb..2c593ec 100644 --- a/doc/about_flashrom/team.rst +++ b/doc/about_flashrom/team.rst @@ -6,8 +6,8 @@ All contributors and users who have a Gerrit account can send patches, add comments to patches and vote +1..-1 on patches. -All contributors and users are expected to follow Development guidelines, -Code of Conduct and Friendliness guidelines. +All contributors and users are expected to follow Development guidelines and +:doc:`code_of_conduct`. There are two special groups in Gerrit. @@ -55,7 +55,7 @@ * From time to time show up in real-time channel(s) and/or dev meetings. -* Follow the Code of Conduct and Friendliness guidelines, be a good example for others. +* Follow the :doc:`code_of_conduct`, be a good example for others. * Bonus point: if you work in a [software] company, educate and help contributors from your company with upstream culture and dev guidelines. -- To view, visit https://review.coreboot.org/c/flashrom/+/78203?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426 Gerrit-Change-Number: 78203 Gerrit-PatchSet: 1 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-MessageType: newchange

1 0

[S] Change in flashrom[main]: erasure_layout: Fix double invocation of erasers
by Anastasia Klimchuk (Code Review) 30 Sep '23

30 Sep '23

Attention is currently required from: Aarya, Alexander Goncharov, Sam McNally. Anastasia Klimchuk has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/77747?usp=email ) Change subject: erasure_layout: Fix double invocation of erasers ...................................................................... Patch Set 4: (1 comment) Patchset: PS3: > I still encounter an error. Added comments and logs in the issue tracker. Thank you! I added one comment to the ticket. If you give me the images I can debug too! I think these are two different issues. The issue this patch is solving is that every block was erased twice: but the end result was correct, so end user would not notice the issues (and verification works too). While I think there are two different issues, I would debug yours as well before deciding to submit this one: just in case. In general, this patch is useful, and also the next one (unit test), I would really want to get it through and have the test running on jenkins. -- To view, visit https://review.coreboot.org/c/flashrom/+/77747?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I92351eba0fd29114ce98b4a839358e92d176af28 Gerrit-Change-Number: 77747 Gerrit-PatchSet: 4 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Reviewer: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Reviewer: Edward O'Callaghan <quasisec(a)chromium.org> Gerrit-Reviewer: Sam McNally <sammc(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Sam McNally <sammc(a)google.com> Gerrit-Attention: Aarya <aarya.chaumal(a)gmail.com> Gerrit-Attention: Alexander Goncharov <chat(a)joursoir.net> Gerrit-Comment-Date: Sat, 30 Sep 2023 10:59:17 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Alexander Goncharov <chat(a)joursoir.net> Gerrit-MessageType: comment

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

flashrom-gerrit