[flashrom] Re: Support for GD25LR512ME flash chip.

[Anastasia Klimchuk]

Hello Avinash,

Sorry for some delay in response. I was also thinking, what's useful
that I could tell you.

I understand your idea to shrink the image to 16MB, so that work
around the bug which affects images >16MB. However, flashrom checks
whether the size of the image is the same as the size of the chip
(should throw an error if not). So to write 16MB onto GD25LR512ME
which is 64MB, you would need to pad the file, with zeros usually, to
make the file 64MB.
I don't know whether it would work. Is it possible that you would try
(if you have tools to recover your device from failure of course)? Or
perhaps you have tried already?

On the other hand, some good news: support for chips GD25LR256E,
GD251R512ME has been submitted meanwhile. So no need for patching
anymore, the patch linked earlier in the thread is merged into main.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: New chip: EN25Q128.

[Anastasia Klimchuk]

Oh, you even went one step further than I suggested: I meant that you
can try the latest released version (1.3), and what you built from
source will eventually go into the next version (1.4). But it seems
that building from source went well, that's good.

About the chip. The chip you initially asked about, EN25Q128, is not
the one that you attached datasheets for, EN25QH128A. And from the
probing results, the ID returned is id1 0x1c, id2 0x7118 which seems
like yet another chip EN25QX128A. The ID returned by probing matches
with what's here:
https://esmt.com.tw/upload/pdf/ESMT/datasheets/EN25QX128A(2V).pdf

Can you double-check which one you have? The first two are supported
already, the latter is not (and this is consistent with the logs you
provided).

If you indeed have EN25QX128A in your hands, maybe you can consider
adding support for it? You are in a good position for doing this: you
have the chip, and you already built flashrom from head.

We have guidelines: https://flashrom.org/contrib_howtos/how_to_add_new_chip.html
Thank you!

On Sat, Jun 8, 2024 at 1:01 AM Rogier Wolff  wrote:
>
> On Fri, Jun 07, 2024 at 11:57:24PM +1000, Anastasia Klimchuk wrote:
> > Hello Rogier,
> >
> > I just checked, EN25Q128 is supported in the latest release 1.3, and
> > from your logs you have 1.2
> > Is it possible for you to upgrade flashrom to the latest version?
>
> I've been "bitten" by upgrading something from source, which required
> an upgrade of a library which in turn messed up my system so that
> weeks later you suddenly find that something you know worked in the
> past no longer works. So I tend to try to use the
> distribution-provided stuff. Now I do think that "upgrading flashrom"
> won't lead to such problems.
>
> OK. Done.
>
> Roger.
>
>
> flashrom 1.4.0-devel (git:v1.2-1460-g1ed95233) on Linux 6.5.0-26-generic 
> (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> flashrom was built with GCC 11.4.0, little endian
> Command line (3 args): flashrom -VV --programmer ch341a_spi
> Initializing ch341a_spi programmer
> Device revision is 3.0.4
> The following protocols are supported: SPI.
> Probing for AMIC A25L010, 128 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L016, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L020, 256 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L032, 4096 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L040, 512 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L05PT, 64 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L05PU, 64 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L080, 1024 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L10PT, 128 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L10PU, 128 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L16PT, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L16PU, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L20PT, 256 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L20PU, 256 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L40PT, 512 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L40PU, 512 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L512, 64 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25L80P, 1024 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25LQ032/A25LQ32A, 4096 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25LQ16, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for AMIC A25LQ64, 8192 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF011, 128 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF021, 256 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF021A, 256 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF041A, 512 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF081, 1024 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF081A, 1024 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF161, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF321, 4096 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF321A, 4096 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DF641(A), 8192 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DL081, 1024 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DL161, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25DQ161, 2048 kB: compare_id: id1 0x1c, id2 0x7118
> Probing for Atmel AT25F1024(A), 128 kB: probe_spi_at25f: id1 0x04, id2 0x04
> Probing for Atmel AT25F2048, 256 kB: probe_spi_at25f: id1 0x04, id2 0x04
> Probing for Atme

[flashrom] Re: New chip: EN25Q128.

[Anastasia Klimchuk]

Hello Rogier,

I just checked, EN25Q128 is supported in the latest release 1.3, and
from your logs you have 1.2
Is it possible for you to upgrade flashrom to the latest version?

On Fri, Jun 7, 2024 at 11:36 PM Rogier Wolff  wrote:
>
> Hi,
>
> I have a bunch of EN25Q128 here. The CH341 programmer that I bought
> recognizes it as 16Mbyte, but ... not "recognized".
>
> So attached is the output of -VV as requested.
>
> Let me know if I can be of any more help. Ah! I'll include the
> datasheet.
>
> (My finger still hurts: I wanted to make sure it was correctly seated
> in the clip that I have No BBQ sounds, but definitively hot. I
> think I checked the orientation, but... Anyway. First chip redirected to
> the bin, second chip gives the attached results!).
>
> Roger.
>
> --
> ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
> **Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
> f equals m times a. When your f is steady, and your m is going down
> your a is going up.  -- Chris Hadfield about flying up the space shuttle.
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Adding support for a new chip

[Anastasia Klimchuk]

Hello!

If you have datasheet for the chip you want to support, you can follow
the guidelines:
https://flashrom.org/contrib_howtos/how_to_add_new_chip.html

But this would also need you to have a dev environment (not the
machine with broken motherboard) and, an external programmer, is this
something that you have?

> How does the process work when recognizing chips ? Would adding this
> chip create a conflict with its predecessor ?

If there are multiple chips with the same model ID, flashrom will tell
you that after probing, and will tell you to pick which one you have
and re-run. There is also details on manpage
https://flashrom.org/classic_cli_manpage.html#options

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Support for GD25LR512ME flash chip.

[Anastasia Klimchuk]

Victor,

Thank you so much for the datasheets! I did a review of the pending
patch, and now it will be possible to finally finish the patch from
2021 and get the chips submitted.

Also thank you for attaching the log.

Not sure if the log is complete? It ends at the start of the reading
operation, but there is no final message of SUCCESS or FAIL.

However, importantly, I could see in the beginning of the log which
platform was detected, and it is Promontory. Which means...

Avinash,

Most likely you are hitting a known issue, you can read more details
here: https://ticket.coreboot.org/issues/370
The issue is for Promontory, and also for chips larger than 16Mbyte:
which is exactly what you have.

I was actually trying to get help from AMD with this issue, so it's
really good to have you here on the mailing list! Maybe you can help?

Someone from AMD would be in the best position to fix Promontory, you
have all the datasheets available, and all the hardware.

Thank you!

On Sat, May 11, 2024 at 9:40 PM Vlim  wrote:
>
> Hi, Anastasia,
>
> Please find the attached datasheet for GD25LR256E and GD25LR512ME.
>
> There are actually two issues.
>
> the released flashrom does not support GD25LR256E and GD25LR512ME.
> With my patch, the dediprog programmer works for GD25LR512ME. But the AMD 
> internal programmer for Birman Plus Board does not work. Output file attached.
>
>
> This is the comment about Birman Plus Board
>
> Now, Flashrom can detect the flash chip.
> Using dediprog programmer I can read/write the flash chip successfully.
> Whereas with using the internal programmer i.e. "-p internal" the read/write 
> is failing. I am attaching the log here.
> Please give your input on this.
>
>
> Regards,
>
> Victor
>
>
> 
> From: Anastasia Klimchuk 
> Sent: Saturday, May 11, 2024 17:59
> To: Vlim ; Munduru, Avinash 
> Cc: flashrom@flashrom.org 
> Subject: Re: [flashrom] Re: Support for GD25LR512ME flash chip.
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> There is another thing, in addition to my previous message.
>
> I looked into the patch which adds chip definitions (this one
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.coreboot.org%2Fc%2Fflashrom%2F%2B%2F58025=05%7C02%7Cvlim%40gigadevice.com%7Cc0befcd8903b4ec8313808dc71a11508%7Cf84ba339959c4ab19b671e43414f945e%7C0%7C0%7C638510183869112409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=xsnzvP2z5zwaBEpEkmgoe5gIOcLBnlae9yDVmuFtEco%3D=0)
>  and the reason it is
> pending is there are no links to datasheets (old links are not working
> anymore).
> It is unfortunate that the patch is pending since 2021, but I want to
> try to fix the situation now, in the year 2024.
>
> Victor, maybe you know, is it possible to find datasheets for
> GD25LR256E and GD251R512ME? I could finish the old patch and get chips
> into the tree.
>
> This is a separate question to Avinash's issue with internal
> programmer, but for this we need the very verbose log (which is log
> with -VVV option on command line).
>
> Thank you!
>
> On Thu, May 9, 2024 at 11:03 PM Anastasia Klimchuk  wrote:
> >
> > Avinash, I read the thread and I see you are saying "I am attaching
> > the log here" but I don't see the log? maybe you can re-send it again,
> > now with the mailing list? (perhaps you sent it to Victor only?)
> > Yes it is also important to know your board, since you are saying the
> > chip worked successfully with dediprog, but not with the internal
> > programmer.
> >
> > Victor, thank you so much for helping!
> >
> >
> > On Mon, May 6, 2024 at 6:42 PM Vlim  wrote:
> > >
> > > Thanks, Avinash,
> > >
> > > Can you advise which board are you using?
> > > I have tested this patch with the USB programmer only since I do not have 
> > > access to the motherboard.
> > >
> > > Hi, Flashrom team,
> > > Can you also help on this?
> > >
> > >
> > > Regards,
> > >
> > > Victor Lim
> > > FAE Director
> > > GigaDevice Semiconductor
> > > 4088833856
> > > v...@gigadevice.com
> > >
> > > 
> > > From: Munduru, Avinash 
> > > Sent: Monday, May 6, 2024 16:24
> > > To: Vlim ; flashrom@flashrom.org 
> > > 
> > > Subject: Re: Support for GD25LR512ME flash chip.
> > >
> > > You don't often get email from avinash.mund...@amd.com. Learn wh

[flashrom] Re: RFC: removing 1 second verification delay

[Anastasia Klimchuk]

Brian, thank you for your work! The patch is submitted.

> Honestly, I don't know how to move forward on assertions about
> "know[ing] for sure whether this delay is no longer needed". We have
> no actionable information about the original problem, so we can never
> be sure.

I have been thinking about it in the background. I feel it's a good
topic to discuss in the meeting.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Support for GD25LR512ME flash chip.

[Anastasia Klimchuk]

There is another thing, in addition to my previous message.

I looked into the patch which adds chip definitions (this one
https://review.coreboot.org/c/flashrom/+/58025) and the reason it is
pending is there are no links to datasheets (old links are not working
anymore).
It is unfortunate that the patch is pending since 2021, but I want to
try to fix the situation now, in the year 2024.

Victor, maybe you know, is it possible to find datasheets for
GD25LR256E and GD251R512ME? I could finish the old patch and get chips
into the tree.

This is a separate question to Avinash's issue with internal
programmer, but for this we need the very verbose log (which is log
with -VVV option on command line).

Thank you!

On Thu, May 9, 2024 at 11:03 PM Anastasia Klimchuk  wrote:
>
> Avinash, I read the thread and I see you are saying "I am attaching
> the log here" but I don't see the log? maybe you can re-send it again,
> now with the mailing list? (perhaps you sent it to Victor only?)
> Yes it is also important to know your board, since you are saying the
> chip worked successfully with dediprog, but not with the internal
> programmer.
>
> Victor, thank you so much for helping!
>
>
> On Mon, May 6, 2024 at 6:42 PM Vlim  wrote:
> >
> > Thanks, Avinash,
> >
> > Can you advise which board are you using?
> > I have tested this patch with the USB programmer only since I do not have 
> > access to the motherboard.
> >
> > Hi, Flashrom team,
> > Can you also help on this?
> >
> >
> > Regards,
> >
> > Victor Lim
> > FAE Director
> > GigaDevice Semiconductor
> > 4088833856
> > v...@gigadevice.com
> >
> > 
> > From: Munduru, Avinash 
> > Sent: Monday, May 6, 2024 16:24
> > To: Vlim ; flashrom@flashrom.org 
> > 
> > Subject: Re: Support for GD25LR512ME flash chip.
> >
> > You don't often get email from avinash.mund...@amd.com. Learn why this is 
> > important
> > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> > This is an external email, beware of phishing emails. Please pay close 
> > attention to whether the email contains sensitive information
> >
> > [AMD Official Use Only - General]
> >
> >
> > Hi Victor,
> >
> > Thanks for sharing the patch. Here is an update after trying the shared 
> > patch.
> >
> > Now, Flashrom can detect the flash chip.
> > Using dediprog programmer I can read/write the flash chip successfully.
> > Whereas with using the internal programmer i.e. "-p internal" the 
> > read/write is failing. I am attaching the log here.
> > Please give your input on this.
> >
> > Once again! Thanks for your help!
> >
> >
> > 
> > From: Vlim 
> > Sent: Sunday, May 5, 2024 1:54 PM
> > To: flashrom@flashrom.org ; Munduru, Avinash 
> > 
> > Subject: Re: Support for GD25LR512ME flash chip.
> >
> > Caution: This message originated from an External Source. Use proper 
> > caution when opening attachments, clicking links, or responding.
> >
> > Hi, Avinash,
> >
> > Sorry that I am working on adding this part to Flashrom, but has not 
> > completed the entire process.
> >
> > Can you please use the attached flashchips.c and flashshchips.h and replace 
> > that in flashrom distribution?
> >
> > This is the process.
> >
> > git clone "https://review.coreboot.org/flashrom;
> >
> > meson setup builddir
> > meson compile -C builddir
> > meson test -C builddir
> > meson install -C builddir
> >
> >
> > Please also refer to the following link for compilation of the code.
> > https://flashrom.org/dev_guide/building_from_source.html
> >
> > I have a compiled version for Ubuntu Linux, if that will help, I can share 
> > with you.
> >
> > Regards,
> >
> > Victor Lim
> > GigaDevice Semiconductors Inc.
> > 4088833856
> > v...@gigadevice.com
> >
> >
> > 
> > From: Munduru, Avinash via flashrom 
> > Sent: Tuesday, April 30, 2024 16:54
> > To: flashrom@flashrom.org 
> > Subject: [flashrom] Re: Support for GD25LR512ME flash chip.
> >
> > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> > This is an external email, beware of phishing emails. Please pay close 
> > attention to whether the email contains sensitive information
> >
> > [AMD Official Use Only - General]
> >
> >
> > + attaching the output log
> >
> > 
> > From: Munduru, Avinash
> > Sent: Tuesday, April 30, 2024 2:04 PM
> > To: flashrom@flashrom.org 
> > Subject: Support for GD25LR512ME flash chip.
> >
> > Hi,
> >
> > Currently, flash chip support for GD25LR512ME is not supported in flashrom 
> > utility.
> > Please share a patch if it is already available. If not let me know how I 
> > can modify it.
> >
> > ___
> > flashrom mailing list -- flashrom@flashrom.org
> > To unsubscribe send an email to flashrom-le...@flashrom.org
>
>
>
> --
> Anastasia.



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Support for GD25LR512ME flash chip.

[Anastasia Klimchuk]

Avinash, I read the thread and I see you are saying "I am attaching
the log here" but I don't see the log? maybe you can re-send it again,
now with the mailing list? (perhaps you sent it to Victor only?)
Yes it is also important to know your board, since you are saying the
chip worked successfully with dediprog, but not with the internal
programmer.

Victor, thank you so much for helping!


On Mon, May 6, 2024 at 6:42 PM Vlim  wrote:
>
> Thanks, Avinash,
>
> Can you advise which board are you using?
> I have tested this patch with the USB programmer only since I do not have 
> access to the motherboard.
>
> Hi, Flashrom team,
> Can you also help on this?
>
>
> Regards,
>
> Victor Lim
> FAE Director
> GigaDevice Semiconductor
> 4088833856
> v...@gigadevice.com
>
> 
> From: Munduru, Avinash 
> Sent: Monday, May 6, 2024 16:24
> To: Vlim ; flashrom@flashrom.org 
> Subject: Re: Support for GD25LR512ME flash chip.
>
> You don't often get email from avinash.mund...@amd.com. Learn why this is 
> important
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> [AMD Official Use Only - General]
>
>
> Hi Victor,
>
> Thanks for sharing the patch. Here is an update after trying the shared patch.
>
> Now, Flashrom can detect the flash chip.
> Using dediprog programmer I can read/write the flash chip successfully.
> Whereas with using the internal programmer i.e. "-p internal" the read/write 
> is failing. I am attaching the log here.
> Please give your input on this.
>
> Once again! Thanks for your help!
>
>
> 
> From: Vlim 
> Sent: Sunday, May 5, 2024 1:54 PM
> To: flashrom@flashrom.org ; Munduru, Avinash 
> 
> Subject: Re: Support for GD25LR512ME flash chip.
>
> Caution: This message originated from an External Source. Use proper caution 
> when opening attachments, clicking links, or responding.
>
> Hi, Avinash,
>
> Sorry that I am working on adding this part to Flashrom, but has not 
> completed the entire process.
>
> Can you please use the attached flashchips.c and flashshchips.h and replace 
> that in flashrom distribution?
>
> This is the process.
>
> git clone "https://review.coreboot.org/flashrom;
>
> meson setup builddir
> meson compile -C builddir
> meson test -C builddir
> meson install -C builddir
>
>
> Please also refer to the following link for compilation of the code.
> https://flashrom.org/dev_guide/building_from_source.html
>
> I have a compiled version for Ubuntu Linux, if that will help, I can share 
> with you.
>
> Regards,
>
> Victor Lim
> GigaDevice Semiconductors Inc.
> 4088833856
> v...@gigadevice.com
>
>
> 
> From: Munduru, Avinash via flashrom 
> Sent: Tuesday, April 30, 2024 16:54
> To: flashrom@flashrom.org 
> Subject: [flashrom] Re: Support for GD25LR512ME flash chip.
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> [AMD Official Use Only - General]
>
>
> + attaching the output log
>
> 
> From: Munduru, Avinash
> Sent: Tuesday, April 30, 2024 2:04 PM
> To: flashrom@flashrom.org 
> Subject: Support for GD25LR512ME flash chip.
>
> Hi,
>
> Currently, flash chip support for GD25LR512ME is not supported in flashrom 
> utility.
> Please share a patch if it is already available. If not let me know how I can 
> modify it.
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: RFC: removing 1 second verification delay

[Anastasia Klimchuk]

Currently, BUS_NONSPI = BUS_PARALLEL | BUS_LPC | BUS_FWH

so it does not include BUS_PROG, and of course not BUS_SPI.
It seems to cover what is needed?

I also need to correct my little piece of code, it actually should be
if (flash->chip->bustype & BUS_NONSPI)
It seems like something everyone can agree on?

The patch saves 1s for every flashrom run, for almost all users, so
it's a good thing. If it can be unblocked now just by adding 1-line
condition, let's unblock it now.

Perhaps there is a bigger question of Parallel/LPC/FWH flash chips
which need special treatment, but rarely used nowadays. I want to
discuss, but as a topic by itself.

I don't think we need to resolve all of the problems in one patch :)

On Fri, Apr 26, 2024 at 8:54 AM Brian Norris  wrote:
>
> Hi Angel,
>
> On Thu, Apr 25, 2024 at 11:44:47AM +, Angel Pons wrote:
> > On Thu, Apr 25, 2024 at 10:26 AM Anastasia Klimchuk  
> > wrote:
>
> > /*
> >  * Work around chips which need some time to calm down.
> >  * Not needed for SPI flash chips because of the bus' strict timing.
> >  */
> > if (flash->chip->bustype != BUS_SPI)
> > programmer_delay(flashctx, 1000*1000);
>
> For the record, linux_mtd is a primary target for all Arm Chromebooks,
> and it registers an opaque programme with BUG_PROG. Presumably an
> "opaque" chip qualifies as "safe enough" too, because the opaque
> abstraction should be taking care of timing details? If not, then this
> is not a sufficient solution for me.
>
> I guess my proposal would probably enumerate the old buses
> (BUS_PARALLEL, BUS_LPC, BUS_FWH) specifically, to avoid further
> unintentional inclusion.
>
> Anyway, I appreciate the general thrust of your thoughts and
> suggestions. I'll reply to a few bits below.
>
> > [The following is a textual representation of my thought processes;
> > it's not particularly necessary but I felt it could be interesting]
>
> Appreciated!
>
> > My idea is to maintain backwards compatibility while still enabling
> > new features and improvements. [...]
>
> I appreciate the attempt at a middle ground here.
>
> > > On Thu, Apr 25, 2024 at 7:35 AM Angel Pons  wrote:
> > > > On Wed, Apr 24, 2024 at 9:16 PM Brian Norris  
> > > > wrote:
> > > > >
> > > > > Background: https://review.coreboot.org/c/flashrom/+/80807
> > > > >
> > > > > A long time ago, in the pre-git times [1], flashrom added a 1 second
> > > > > delay to all verification, and claimed that some chips "need some time
> > > > > to calm down." The commit message claims it "fixes a few reports where
> > > > > verify directly after erase had unpleasant side effects like
> > > > > corrupting flash or at least getting incorrect verify results." It
> > > > > provides no details of what systems, chips, or programmers were
> > > > > involved.
> > > >
> > > > Back then, SPI flash chips weren't as ubiquitous as they currently
> > > > are. This workaround is most likely for Parallel/LPC/FWH flash chips,
> > > > which can actually be quite weird.
>
> Interesting callout. I've dealt with some parallel NOR as well in the
> past, and I don't really recall magical sleeps there either. Look around
> at Linux's drivers/mtd/chips/cfi* for example. There's some incidence of
> udelay()/msleep()/etc., but they're coupled with status checks and
> polling loops, similar to any SPI protocol. The only exception I found
> is a verbosely documented cfi_fixup_m29ew_delay_after_resume() sleep.
> And even that's only 0.5 milliseconds.
>
> But I suppose the existence of good parallel flash drivers doesn't
> preclude the existence of poor ones elsewhere.
>
> Do you have any kind of examples of what "weirdness" might be present
> here? Or is this just a general feeling and guess based on the year of
> the original change?
>
> > > > If we don't know for sure whether this delay is no longer needed, I
> > > > wouldn't risk re-introducing issues in flashrom.
>
> I don't think that condition is possible to satisfy given sufficiently
> under-documented "fixes" from ancient history. I appreciate that we
> don't want to regress things, but when there's no evidence or details of
> the initial problem, it's logically impossible to prove its
> non-existence now.
>
> But toward a non-guaranteed proof: see consideration #3 in my
> aforementioned patch. We already perform verify-after-erase steps
> without any such delay. Wouldn't this path be affected in the same way,
> if it was still a real probl

[flashrom] Re: RFC: removing 1 second verification delay

[Anastasia Klimchuk]

Angel, great to see you here again! Also, you provided very useful information.

> Did you conside making it so that only SPI programmers / flash chips
> skip the delay? The SPI bus' strict timing leaves no room for this
> problem to occur, so it should be safe to skip this delay. And this
> would keep non-SPI unaffected (which is most likely what needs this
> extra delay).

This sounds interesting.
If we check for non-SPI chips, it only adds one more line to the patch
(if I understand your idea correctly):

if (flash->chip->bustype == BUS_NONSPI)

On Thu, Apr 25, 2024 at 7:35 AM Angel Pons  wrote:
>
> Hi Brian, list,
>
> Thanks for bringing this up on the mailing list.
>
> On Wed, Apr 24, 2024 at 9:16 PM Brian Norris  wrote:
> >
> > Background: https://review.coreboot.org/c/flashrom/+/80807
> >
> > A long time ago, in the pre-git times [1], flashrom added a 1 second
> > delay to all verification, and claimed that some chips "need some time
> > to calm down." The commit message claims it "fixes a few reports where
> > verify directly after erase had unpleasant side effects like
> > corrupting flash or at least getting incorrect verify results." It
> > provides no details of what systems, chips, or programmers were
> > involved.
>
> Back then, SPI flash chips weren't as ubiquitous as they currently
> are. This workaround is most likely for Parallel/LPC/FWH flash chips,
> which can actually be quite weird.
>
> > This delay remains in the --verify path today, and IMO, it's a big
> > waste of time. If there are truly chips that are, say, deasserting the
> > BUSY line before they're truly finished programming ... well, we
> > should track those chips down and add targeted quirk flags for them.
> > We shouldn't penalize all flashrom users in all cases for all time.
>
> I agree that this delay shouldn't be unconditional.
>
> > Personally, I highly doubt that this delay is still relevant today --
> > there may have been a bug in some programmer that has since been
> > fixed; there may have been some malfunctioning system that is no
> > longer in use; ... or it's possible this is still hiding a real buggy
> > chip somewhere out there.
>
> If we don't know for sure whether this delay is no longer needed, I
> wouldn't risk re-introducing issues in flashrom.
>
> > I propose: we still remove the delay. There's plenty of description in
> > the above Gerrit link about why, and how we can handle regressions.
> > (For one, it's relatively simple to split up a --verify operation into
> > its constituent --write/sleep/--read operations, for debugging.)
> >
> > The request:
> > 1. Tests: I've tested a few Chromebooks, but imagine this had to have
> > been some more esoteric system. Extra testing is welcome.
>
> Do Chromebooks use non-SPI flash chips? They probably don't.
>
> > 2. Thoughts: does my proposal make sense? Am I missing something obvious?
>
> Did you conside making it so that only SPI programmers / flash chips
> skip the delay? The SPI bus' strict timing leaves no room for this
> problem to occur, so it should be safe to skip this delay. And this
> would keep non-SPI unaffected (which is most likely what needs this
> extra delay).
>
> > 3. Awareness: if nothing else, this email may serve to highlight in
> > case we land the above patch and later hear back that there are some
> > sketchy --verify reports from users.
>
> I agree that awareness is important, but bear in mind that external
> programmers for non-SPI flash chips are increasingly rare, so
> recovering from a brick can be quite convoluted (e.g. having to
> desolder a TSOP32 flash chip to reflash it somehow).
>
> > Thanks,
> > Brian
> >
> > [1] The svn->git commit in question:
> >
> >   commit 8ab49e72af8465d4527de2ec37b22cd44f7a1169
> >   Date:   Wed Aug 19 13:55:34 2009 +
> >   Disallow erase/write for known bad chips so people won't try without
> > a clear understanding
> > ___
> > flashrom mailing list -- flashrom@flashrom.org
> > To unsubscribe send an email to flashrom-le...@flashrom.org
>
> Best regards,
> Angel
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: adding part #

[Anastasia Klimchuk]

This is good news, I can see your patch!

You pushed your patch successfully, which you can see from the logs
you posted earlier, and also the logs contain the link to the patch
(https://review.coreboot.org/c/flashrom/+/81970 in this case).
You can click the link and inspect how your patch looks, how Gerrit UI
looks. View-only mode is public (you can send the link to anyone), but
to modify your patch, respond to comments etc, you need to be logged
into Gerrit.

Next steps are documented in the section "Going through code reviews"
here 
https://flashrom.org/dev_guide/development_guide.html#going-through-code-reviews

During the code review process communication is happening in Gerrit
(not in the mailing list).

So your immediate next step is to wait for reviewer(s) to go through
your patch and add comments, it will happen soon. And then you need to
fix and respond to comments. There are more details in the doc I
linked.
Thank you for your work! And keep an eye on your patch when the comments arrive.


On Fri, Apr 19, 2024 at 6:03 AM Vlim  wrote:
>
> Thanks,
>
> I think I am getting closer. What do I do next?
>
> Regards,
>
> Victor
>
>
> victor@victor-0-1:~/Desktop/flashrom$ git push upstream HEAD:refs/for/main
> Username for 'https://review.coreboot.org': victorswlim
> Password for 'https://victorsw...@review.coreboot.org':
> Enumerating objects: 9, done.
> Counting objects: 100% (9/9), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (5/5), 1.74 KiB | 445.00 KiB/s, done.
> Total 5 (delta 4), reused 0 (delta 0), pack-reused 0
> remote: Resolving deltas: 100% (4/4)
> remote: Processing changes: refs: 1, new: 1, done
> remote:
> remote: SUCCESS
> remote:
> remote:   https://review.coreboot.org/c/flashrom/+/81970 : 
> adding a few new SPI NOR part numbers [NEW]
> remote:
> To https://review.coreboot.org/flashrom
>  * [new reference] HEAD -> refs/for/main
>
>
> 
> From: Anastasia Klimchuk 
> Sent: Thursday, April 18, 2024 03:36
> To: Vlim ; Nikolai Artemiev ; 
> flashrom@flashrom.org ; Peter Marheine 
> 
> Subject: Re: [flashrom] Re: adding part #
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
> You need to be logged into your Github account, and then open Gerrit login 
> link and click "GitHub OAuth2".
>
> On Thu, Apr 18, 2024 at 3:33 PM Vlim  wrote:
>
> Hi, Anastasia,
>
> Looks like I am not able to create an account on 
> https://review.coreboot.org/login
>
> This is what I got. And the account I have created on Github.
>
> Regards,
>
> Victor
>
>
> victor@victor-0-1:~/Desktop/flashrom$ git push upstream HEAD:refs/for/main
> Username for 'https://review.coreboot.org': victorswlim1
> Password for 'https://victorswl...@review.coreboot.org':
> remote: Unauthorized
> fatal: Authentication failed for 'https://review.coreboot.org/flashrom/'
>
>
>
> 
> From: Anastasia Klimchuk 
> Sent: Wednesday, April 17, 2024 21:50
> To: Vlim ; Nikolai Artemiev ; 
> flashrom@flashrom.org ; Peter Marheine 
> 
> Subject: Re: [flashrom] Re: adding part #
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> It seems like you created a commit locally, that's good!
> Next instructions are to push your patch to Gerrit, here:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.org%2Fdev_guide%2Fdevelopment_guide.html%23working-with-gerrit-1=05%7C02%7Cvlim%40gigadevice.com%7C0b09f658b282474a853f08dc5f631fbd%7Cf84ba339959c4ab19b671e43414f945e%7C0%7C0%7C638490126569576897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=jepI7tFHfjvtk4sWqS00gM9HXv3tq4f6o4%2FelRZWVFM%3D=0
>
> On Thu, Apr 18, 2024 at 2:13 PM Vlim  wrote:
> >
> > Hi, Anastasia,
> >
> > I am a little lost. Can you advise I should do next.
> > I am getting to the following step.
> >
> > Regards,
> >
> > Victor
> >
> >
> > victor@victor-0-1:~/Desktop/flashrom$ git commit -a -s
> > [upstream/main 4b717ed3] : adding a few new SPI NOR part 
> > numbers
> >  2 files changed, 742 insertions(+), 24 deletions(-)
> > victor@victor-0-1:~/Desktop/flashrom$ git log
> > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main)
> > Author: Victor Lim 
> > Date:   Wed Apr 17 20:53:44 2024 -0700
> >
> > : adding a few new SPI NOR p

[flashrom] Re: adding part #

[Anastasia Klimchuk]

en 
> Date:   Thu Mar 7 18:46:10 2024 +0800
>
> :...skipping...
> commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main)
> Author: Victor Lim 
> Date:   Wed Apr 17 20:53:44 2024 -0700
>
> : adding a few new SPI NOR part numbers
>
> These are the part # added
> GD25LB128E: 1.8V 128Mbit QE = 1
> GD25LQ128E: 1.8V 128Mbit
> GD25LR128E: 1.8V 128Mbit RPMC
> GD25LB256F: 1.8V 256Mbit QE = 1
> GD25LQ256H: 1.8V 256Mbit
> GD25LR256F: 1.8V 256Mbit RPMC
> GD25LB512MF: 1.8V 512Mbit QE = 1
> GD25LR512MF: 1.8V 512Mbit RPMC
> GD25LF128E: 1.8V 128Mbit
> GD25LF256F: 1.8V 256Mbit
> GD25LF512MF: 1.8V 512Mbit
> GD25LB256E: 1.8V 256Mbit QE = 1
> GD25LB512ME: 1.8V 512Mbit QE = 1
> GD25B128E: 3V 128Mbit QE = 1
> GD25Q128E: 3V 128Mbit
> GD25R128E: 3V 128Mbit RPMC
> GD25B256E: 3V 256Mbit QE = 1
> GD25Q256E: 3V 256Mbit
> GD25R256E: 3V 256Mbit RPMC
> GD25B512MF: 3V 512Mbit QE = 1
> GD25R512MF: 3V 512Mbit RPMC
> GD25F64F: 3V 64Mbit
> GD25F128F: 3V 128Mbit
> GD25F256F: 3V 256Mbit
> GD25F512MF: 3V 512Mbit
> GD25B512ME: 3V 512Mbit QE = 1
>
> Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2
> Signed-off-by: Victor Lim 
>
> commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, 
> main)
> Author: Hsuan Ting Chen 
> Date:   Thu Mar 7 18:46:10 2024 +0800
>
> classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi
> :...skipping...
> commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main)
> Author: Victor Lim 
> Date:   Wed Apr 17 20:53:44 2024 -0700
>
> : adding a few new SPI NOR part numbers
>
> These are the part # added
> GD25LB128E: 1.8V 128Mbit QE = 1
> GD25LQ128E: 1.8V 128Mbit
> GD25LR128E: 1.8V 128Mbit RPMC
> GD25LB256F: 1.8V 256Mbit QE = 1
> GD25LQ256H: 1.8V 256Mbit
> GD25LR256F: 1.8V 256Mbit RPMC
> GD25LB512MF: 1.8V 512Mbit QE = 1
> GD25LR512MF: 1.8V 512Mbit RPMC
> GD25LF128E: 1.8V 128Mbit
> GD25LF256F: 1.8V 256Mbit
> GD25LF512MF: 1.8V 512Mbit
> GD25LB256E: 1.8V 256Mbit QE = 1
> GD25LB512ME: 1.8V 512Mbit QE = 1
> GD25B128E: 3V 128Mbit QE = 1
> GD25Q128E: 3V 128Mbit
> GD25R128E: 3V 128Mbit RPMC
> GD25B256E: 3V 256Mbit QE = 1
> GD25Q256E: 3V 256Mbit
> GD25R256E: 3V 256Mbit RPMC
> GD25B512MF: 3V 512Mbit QE = 1
> GD25R512MF: 3V 512Mbit RPMC
> GD25F64F: 3V 64Mbit
> GD25F128F: 3V 128Mbit
> GD25F256F: 3V 256Mbit
> GD25F512MF: 3V 512Mbit
> GD25B512ME: 3V 512Mbit QE = 1
>
> Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2
> Signed-off-by: Victor Lim 
>
> commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, 
> main)
> Author: Hsuan Ting Chen 
> Date:   Thu Mar 7 18:46:10 2024 +0800
>
> classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi
>
> :...skipping...
> commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main)
> Author: Victor Lim 
> Date:   Wed Apr 17 20:53:44 2024 -0700
>
> : adding a few new SPI NOR part numbers
>
> These are the part # added
> GD25LB128E: 1.8V 128Mbit QE = 1
> GD25LQ128E: 1.8V 128Mbit
> GD25LR128E: 1.8V 128Mbit RPMC
> GD25LB256F: 1.8V 256Mbit QE = 1
> GD25LQ256H: 1.8V 256Mbit
> GD25LR256F: 1.8V 256Mbit RPMC
> GD25LB512MF: 1.8V 512Mbit QE = 1
> GD25LR512MF: 1.8V 512Mbit RPMC
> GD25LF128E: 1.8V 128Mbit
> GD25LF256F: 1.8V 256Mbit
> GD25LF512MF: 1.8V 512Mbit
> GD25LB256E: 1.8V 256Mbit QE = 1
> GD25LB512ME: 1.8V 512Mbit QE = 1
> GD25B128E: 3V 128Mbit QE = 1
> GD25Q128E: 3V 128Mbit
> GD25R128E: 3V 128Mbit RPMC
> GD25B256E: 3V 256Mbit QE = 1
> GD25Q256E: 3V 256Mbit
> GD25R256E: 3V 256Mbit RPMC
> GD25B512MF: 3V 512Mbit QE = 1
> GD25R512MF: 3V 512Mbit RPMC
> GD25F64F: 3V 64Mbit
> GD25F128F: 3V 128Mbit
> GD25F256F: 3V 256Mbit
> GD25F512MF: 3V 512Mbit
> GD25B512ME: 3V 512Mbit QE = 1
>
> Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2
> Signed-off-by: Victor Lim 
>
> commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, 
> main)
> Author: Hsuan Ting Chen 
> Date:   Thu Mar 7 18:46:10 2024 +0800
>
> classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi
>
> Update technical details for custom_rst of raiden_debug_spi to help
> users better understand their configuration options.
>
> BUG=b:161745002
> BRAN

[flashrom] Re: adding part #

[Anastasia Klimchuk]

This is really good news! I am so glad to hear that you are almost
there. Thank you for your effort!

We have the advice and instructions documented in Development Guide
here: https://flashrom.org/dev_guide/development_guide.html
And maybe you read this doc already, but if not, it's a good time to
read it before pushing a patch.

On Sat, Apr 13, 2024 at 3:46 AM Vlim  wrote:
>
> Hi, Anastasia,
>
> It was due to the ch341a_spi not stable after my modification.
> The on-board controller was powered by a 5V supply, and output signals are 5V.
> I changed the power to 3V, since then, it was not stable sometimes.
> After adding a cap to the 3V line close to the controller, it is ok now.
>
> I have almost finished verification for the new part #s to be added.
> Expecting to submit the patch in a few days.
> Do you have any advice for me about submitting the patch?
>
> Files I have modified are Flashchip.c and .h.
>
> Regards,
>
> Victor
>
> ____
> From: Anastasia Klimchuk 
> Sent: Friday, April 12, 2024 02:25
> To: Vlim ; Nikolai Artemiev ; 
> flashrom@flashrom.org ; Peter Marheine 
> 
> Subject: Re: [flashrom] Re: adding part #
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> This looks like timeout might be happening because of how your
> programmer device is set up, not necessarily because the chip
> definition is wrong. I remember often people say about ch341a_spi
> "check the wires are not too long", maybe this applies to you?
>
> Also, you need to give more info:
>
> the exact command you ran
> and full verbose logs (-VVV gives you super verbose mode)
> also what are your current local changes? I assume you run it on your
> local commit? you can push a patch and mark it "work in progress" so
> that we know what is the actual code that you are running.
>
> On Tue, Apr 9, 2024 at 3:04 PM Vlim  wrote:
> >
> > Thanks.
> >
> > Another question.
> > I am getting the following message, please advise what is the possible 
> > issue?
> >
> > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> > Found GigaDevice flash chip "GD25F64F" (8192 kB, SPI) on ch341a_spi.
> > Reading old flash chip contents... done.
> >
> > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
> > ch341a_spi_spi_send_command: Failed to read 3 bytes
> > Register read failed!
> > write_flash: failed to write (0x66b200..0x66b7ff).
> > Write failed at 0x5, Abort.
> > Erase/write done from 0 to 7f
> > Write Failed!Uh oh. Erase/write failed. Checking if anything has changed.
> > Reading current flash chip contents...
> > cb_out: error: LIBUSB_TRANSFER_TIMED_OUT
> >
> > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
> >
> > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
> >
> > Regards,
> >
> > Victor
> >
> > 
> > From: Anastasia Klimchuk 
> > Sent: Monday, April 8, 2024 06:00
> > To: Vlim ; Nikolai Artemiev ; 
> > flashrom@flashrom.org ; Peter Marheine 
> > 
> > Subject: Re: [flashrom] Re: adding part #
> >
> > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> > This is an external email, beware of phishing emails. Please pay close 
> > attention to whether the email contains sensitive information
> >
> > If I understand your question correctly, `–wp-status` command should
> > give you the info:
> > Prints the flash’s current status register protection mode and write
> > protection range.
> >
> > Probably you have looked at that already, but just in case all
> > available commands are in the man page, or also can be read here:
> > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.org%2Fclassic_cli_manpage.html=05%7C02%7Cvlim%40gigadevice.com%7C7674b96ca64c4cf1d25908dc5ad27f1f%7Cf84ba339959c4ab19b671e43414f945e%7C0%7C0%7C638485107372816736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=7qDw7cCwvjnPQrJRxMm%2BptaeUIyQSDTNoHAjO2xPIdw%3D=0
> >
> >
> > On Sun, Apr 7, 2024 at 7:55 AM Vlim  wrote:
> > >
> > > Looked at it further and understood that it is determined by the BPx 
> > > bits, tb bit.
> > > Is there a way I can read the status registers to make sure that all 
> > > these bits match with the datasheet?
> > >
> > > Regards,
> > >
> > > Victor
> > >
> > >
> > > 
> > > From: Vlim 
> >

[flashrom] Re: adding part #

[Anastasia Klimchuk]

This looks like timeout might be happening because of how your
programmer device is set up, not necessarily because the chip
definition is wrong. I remember often people say about ch341a_spi
"check the wires are not too long", maybe this applies to you?

Also, you need to give more info:

the exact command you ran
and full verbose logs (-VVV gives you super verbose mode)
also what are your current local changes? I assume you run it on your
local commit? you can push a patch and mark it "work in progress" so
that we know what is the actual code that you are running.

On Tue, Apr 9, 2024 at 3:04 PM Vlim  wrote:
>
> Thanks.
>
> Another question.
> I am getting the following message, please advise what is the possible issue?
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Found GigaDevice flash chip "GD25F64F" (8192 kB, SPI) on ch341a_spi.
> Reading old flash chip contents... done.
>
> cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
> ch341a_spi_spi_send_command: Failed to read 3 bytes
> Register read failed!
> write_flash: failed to write (0x66b200..0x66b7ff).
> Write failed at 0x5, Abort.
> Erase/write done from 0 to 7f
> Write Failed!Uh oh. Erase/write failed. Checking if anything has changed.
> Reading current flash chip contents...
> cb_out: error: LIBUSB_TRANSFER_TIMED_OUT
>
> cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
>
> cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
>
> Regards,
>
> Victor
>
> 
> From: Anastasia Klimchuk 
> Sent: Monday, April 8, 2024 06:00
> To: Vlim ; Nikolai Artemiev ; 
> flashrom@flashrom.org ; Peter Marheine 
> 
> Subject: Re: [flashrom] Re: adding part #
>
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
>
> If I understand your question correctly, `–wp-status` command should
> give you the info:
> Prints the flash’s current status register protection mode and write
> protection range.
>
> Probably you have looked at that already, but just in case all
> available commands are in the man page, or also can be read here:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.org%2Fclassic_cli_manpage.html=05%7C02%7Cvlim%40gigadevice.com%7C4a985ef0e8814afd275908dc57cbf30f%7Cf84ba339959c4ab19b671e43414f945e%7C0%7C0%7C638481780720654286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=loxAQPEWneQgWDlahCT1XZta0HrzfVPtM5GXkiT0qtQ%3D=0
>
>
> On Sun, Apr 7, 2024 at 7:55 AM Vlim  wrote:
> >
> > Looked at it further and understood that it is determined by the BPx bits, 
> > tb bit.
> > Is there a way I can read the status registers to make sure that all these 
> > bits match with the datasheet?
> >
> > Regards,
> >
> > Victor
> >
> >
> > 
> > From: Vlim 
> > Sent: Friday, April 5, 2024 20:37
> > To: Nikolai Artemiev ; Anastasia Klimchuk 
> > 
> > Cc: flashrom@flashrom.org ; Peter Marheine 
> > 
> > Subject: Re: [flashrom] Re: adding part #
> >
> > Thanks.
> >
> > How are the protection ranges defined?
> > My device has ½ to 1/512.
> > So I am missing 1/128, 1/256, 1/512.
> > And I am getting some extra from 1/1024 to 1/8192.
> >
> > Please advise.
> >
> > Regards,
> >
> > Victor
> >
> >
> >
> > 
> > From: Nikolai Artemiev 
> > Sent: Tuesday, March 26, 2024 18:54
> > To: Anastasia Klimchuk 
> > Cc: Vlim ; flashrom@flashrom.org 
> > ; Peter Marheine 
> > Subject: Re: [flashrom] Re: adding part #
> >
> > You don't often get email from nartem...@google.com. Learn why this is 
> > important
> > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> > This is an external email, beware of phishing emails. Please pay close 
> > attention to whether the email contains sensitive information
> > Hi Victor,
> >
> > One thing to note with the printlock and unlock functions you mentioned 
> > earlier, i.e.:
> >
> > .printlock  = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD,
> > .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD,
> >
> > These functions basically just allow flashrom to remove memory protection 
> > before writing to the chip. They can (and should) be omitted if you define 
> > reg_bits and decode_range in the chip entry, because that will enable full 
> > writeprotect support for the chip.
> >
> > The reason we still have unlock and printlock functions is for older chips 
>

[flashrom] Re: adding part #

[Anastasia Klimchuk]

If I understand your question correctly, `–wp-status` command should
give you the info:
Prints the flash’s current status register protection mode and write
protection range.

Probably you have looked at that already, but just in case all
available commands are in the man page, or also can be read here:
https://flashrom.org/classic_cli_manpage.html


On Sun, Apr 7, 2024 at 7:55 AM Vlim  wrote:
>
> Looked at it further and understood that it is determined by the BPx bits, tb 
> bit.
> Is there a way I can read the status registers to make sure that all these 
> bits match with the datasheet?
>
> Regards,
>
> Victor
>
>
> 
> From: Vlim 
> Sent: Friday, April 5, 2024 20:37
> To: Nikolai Artemiev ; Anastasia Klimchuk 
> 
> Cc: flashrom@flashrom.org ; Peter Marheine 
> 
> Subject: Re: [flashrom] Re: adding part #
>
> Thanks.
>
> How are the protection ranges defined?
> My device has ½ to 1/512.
> So I am missing 1/128, 1/256, 1/512.
> And I am getting some extra from 1/1024 to 1/8192.
>
> Please advise.
>
> Regards,
>
> Victor
>
>
>
> ____
> From: Nikolai Artemiev 
> Sent: Tuesday, March 26, 2024 18:54
> To: Anastasia Klimchuk 
> Cc: Vlim ; flashrom@flashrom.org 
> ; Peter Marheine 
> Subject: Re: [flashrom] Re: adding part #
>
> You don't often get email from nartem...@google.com. Learn why this is 
> important
> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> This is an external email, beware of phishing emails. Please pay close 
> attention to whether the email contains sensitive information
> Hi Victor,
>
> One thing to note with the printlock and unlock functions you mentioned 
> earlier, i.e.:
>
> .printlock  = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD,
> .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD,
>
> These functions basically just allow flashrom to remove memory protection 
> before writing to the chip. They can (and should) be omitted if you define 
> reg_bits and decode_range in the chip entry, because that will enable full 
> writeprotect support for the chip.
>
> The reason we still have unlock and printlock functions is for older chips 
> that don't have reg_bits and decode_range defined.
>
> Cheers,
> Nik
>
>
>
> On Tue, Mar 26, 2024 at 4:32 PM Anastasia Klimchuk  wrote:
>
> I will try to answer to everything in one message, but feel free to
> ask more questions
>
> > Can you point me to the file that defines the commands?
>
> Most of them will be in include/spi.h
>
> It is a longer way if you want to trace implementation from, for
> example SPI_CHIP_READ, to the place where command is sent, but in case
> you would need it:
>
> you would need to go through the sequence of function calls, starting
> from `spi_chip_read` in spi.c and then look into the programmer code
> (for whichever is the programmer you are using) and see how that
> programmer implements spi read and send commands. Specifically look
> for `static const struct spi_master` in the programmer source code
> file.
>
> Default functions are in spi.c and spi25.c files.
>
> > How is Dual IO and Quad IO supported here?
>
> Currently not implemented, however it would be really great to
> implement it in the future (contributions are very welcome).
> We do have those aspirational comments in flashchips.c , for example
> (I am just copying from some chip)
>
> .write = SPI_CHIP_WRITE256, /* Dual I/O  (0xA2) supported */
> .read = SPI_CHIP_READ, /* Fast read (0x0B), dual I/O  (0x3B) supported */
>
> So maybe you can add similar comments for the chip definition for now.
>
> On Tue, Mar 26, 2024 at 5:27 AM Vlim  wrote:
> >
> > Hi,
> >
> > Can you point me to the file that defines the commands?
> > Like SPI_CHIP_READ being 0x0b.
> >
> > Thanks,
> >
> > Victor
> >
> > 
> > From: Anastasia Klimchuk 
> > Sent: Thursday, March 21, 2024 23:32
> > To: Vlim ; flashrom@flashrom.org 
> > 
> > Cc: Peter Marheine 
> > Subject: Re: [flashrom] Re: adding part #
> >
> > [You don't often get email from a...@chromium.org. Learn why this is 
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息
> > This is an external email, beware of phishing emails. Please pay close 
> > attention to whether the email contains sensitive information
> >
> > For these two (printlock and unlock), you need to pick the function
> > which handles the highest BP bit that chip supports. In your example,
> > if a chip supports bits BP0-BP4 the correct functions are those with
>

[flashrom] Re: Failed - HP Elite 3800 SFF Macronix MX25L12835E

[Anastasia Klimchuk]

Hello,

> I checked the MXIC comparison of these chips and they are very similar.
> The main difference with the 35E is the physical pinout is different.

Do you mean you compared the datasheets?
I suspect that multi-chip definition
MX25L12835F/MX25L12845E/MX25L12865E (which at head already grew to
MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F) can cover
you chip as well, but this needs a look at the datasheets to tell for
sure. That's why I am asking.

> I am using a System Rescue USB drive to run Flashrom

Are you rescuing the system which is already broken? If you make a
mistake, would you be able to re-run?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: RFC: remove the calibrated delay loop

[Anastasia Klimchuk]

> do you want to keep around such legacy code
> (increasing the maintenance load) in the codebase forever?

No I don't want to keep such code forever to maintain, mainly because
it won't be needed forever.
But dropping support for DOS will be a separate effort (with dedicated
threads and announcements). I don't think it should be like "while we
are here, let's also drop DOS", it's a bigger effort than "while we
are here".

> For example, some chips use the toggle bit detection to check for a
> finished write.

Do you know, are such chips marked in flashchips definition, how do we
know which ones are like this?
I understand from your words this is a subset of older non-SPI
(LPC/FWH/parallel) flash chips but which ones?

Also relevant to delays: are those the same chips that need extra delay 1s?
For context, comments here https://review.coreboot.org/c/flashrom/+/80807
Do you maybe remember how to find them in flashchips?

As I understand, there are some small(?) number of older(?) chips
which need special treatment on delays, it would be so helpful to find
out which ones exactly.

> Focusing on the 99% might yield enormous
> cleanup opportunities.

Yes, that's a really good observation.
I have such thoughts in the background.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Add support for new flash chip

[Anastasia Klimchuk]

Hello Sol,

If you have time and energy, you can try and add the support yourself.
Do you have the chip to test it?

There are two relevant docs on the topic:
Dev guide https://www.flashrom.org/dev_guide/development_guide.html
and how to add chip
https://wiki.flashrom.org/Development_Guidelines#Adding/reviewing_a_new_flash_chip

Also I am planning to modernise the doc "how to add a new chip" soon,
but meanwhile you can use the existing one.
Thank you!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Report chip Atmel AT29C010A (write)

[Anastasia Klimchuk]

Sol, thank you for reporting. I created a patch to mark the chip as
tested https://review.coreboot.org/c/flashrom/+/78069

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom meeting notes 14.09.2023

[Anastasia Klimchuk]

# 14th September 2023, 6.00-7.00am UTC+0

Attendees: Stefan, Anastasia

## Decision summary

* Renaming flashrom branch from "master" to "main" in the very near
future. All patches in Gerrit will be converted with the script.

## Agenda

* [Stefan] Renaming flashrom branch from "master" to "main" (coreboot
did it already, no issues)
* We can switch all pending patches in gerrit via the script, no
issues with that
* Let's send two announcements: 1) we are renaming the master
branch to main at DD/MM 2) after this is done on DD/MM, send a second
announcement "this is done, here are instructions how to update local
repo".
* Stefan will do all of that
* nothing to do for developers right now, and then after the
second email sent follow the instructions in that email
* aklm will update dev guide (git commands)
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom meeting notes 31.08.2023

[Anastasia Klimchuk]

# 31th August 2023, 6.00-7.00am UTC+0

Attendees: Stefan, Alex, Anastasia

## Decision summary

* not much

## Agenda

* Who is using libpayload, which state it is in, how to test it before release?
* write a post to the mailing list
* see how it goes. if no one responds, can we at least try to compile it
* Libflashrom versioning?
* 
[https://ticket.coreboot.org/issues/381](https://ticket.coreboot.org/issues/381)
* probably can keep it as is for 1.4

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: RDID Values Constantly Changing

[Anastasia Klimchuk]

Ryne, do you have logs by any chance? From two different times you ran
flashrom and got different ids?
You can attach or you can use paste.flashrom.org
Thank you!

On Thu, Aug 24, 2023 at 1:53 PM Ryne Everett  wrote:
>
> Hello group,
>
> I'm attempting to flash a W25Q64FW with a CH341A. Despite this chip's
> RDID being supported (under "W25Q64.W"), flashrom identifies it as an
> "unknown SPI chip (RDID)" which I presume explains the "status NOT
> WORKING for operations: PROBE READ ERASE WRITE".
>
> Upon further inspection with '-VV' I see that id1 and id2 are not only
> wrong -- they're different every time I run flashrom! What could cause
> this?
>
> Thanks,
> Ryne
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] dev feature enabled: unresolved comments block submit

[Anastasia Klimchuk]

Hello everyone,

An announcement to everyone who is doing (or planning to do) any
flashrom development.

Since today, we are enabling the feature in Gerrit which blocks patch
submit until all comments are resolved. You can see it in Gerrit if
you open any patch, in the top-left section, "All-Comments-Resolved"
label.
If all the comments are resolved, the label is marked with a green checkbox.
If there are unresolved comments, the label says "No votes" and submit
is blocked.
Thanks heaps to Patrick for helping to set this up!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom meeting notes 17.08.2023

[Anastasia Klimchuk]

# 17th August 2023, 6.00-7.00am UTC+0

Attendees: Joursoir, Stefan, Anastasia

## Decision summary

* logo files will be copied from flashrom-media to flashrom repo (into
doc/ to display on website)
* enable Gerrit feature to not submit with unresolved comments

## Agenda

* [aklm] is it okay to copy the logo from one repo to another and add
it to new website? Any licensing considerations?
* copy the whole logo directory from media repository to docs
* include svg in color on the page
* licence is CC BY-ND 4.0
[https://github.com/flashrom/flashrom-media/blob/master/logo/COPYING](https://github.com/flashrom/flashrom-media/blob/master/logo/COPYING)
so all good
* What is the normal release process? what do we do for v1.4?
* when all that is needed for rc1 is ready, put the tag v1.4_rc1 on master
* then freeze the master for new features for 1 month, announce on
mailing list
* code reviews can continue, just not merging
* do the testing
* fix bugs if discovered, put v1.4_rc2,  rcN
* at the end of 1 month (hopefully bugs are fixed), put v1.4 on
master, and then branch v1.4
* and then unfreeze, and merge everything that was waiting
* [aklm] we need more people to subscribe to flashchips.c. I did
already. We have contributors adding chips, and marking chips as
tested, and they may not know whom to add as reviewer.
[https://review.coreboot.org/q/status:open+project:flashrom+flashchips](https://review.coreboot.org/q/status:open+project:flashrom+flashchips)
* like this
[https://review.coreboot.org/c/flashrom/+/75895](https://review.coreboot.org/c/flashrom/+/75895)
*
* let's add gerrit feature "do not submit with unresolved comments".
it makes life easier for people who submit patches.
* yes, lets add this feature
* Joursoir: get a warning (do NOT restrict) if 24 hours have not
passed. Is it possible?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: ISSI Flash parts request to be added

[Anastasia Klimchuk]

Hi Johnny,

Question marks mean that the operation in that column is untested for
this chip, untested on hardware. Usually it happens when chip
definition is added based on datasheets information, but without
testing on hw. Later if someone runs operations on the chip
successfully, the chip can be marked as tested. Also sometimes chip
definition is added and tested straight away.

This table on the website might not be fully up-to-date, and the best
I would recommend is to look at the source , flashchips.c. This file
contains all chip definitions and is fairly readable by the human eye
(and you can search by chip name).
If you need to look the source it in the browser for any reason, you
can look in our github mirror:
https://github.com/flashrom/flashrom/blob/master/flashchips.c

I just looked, and the question marks in your screenshot are still
untested chips.
Hope this helps.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: ISSI Flash parts request to be added

[Anastasia Klimchuk]

Hi Johnny,

Good that you reached out. Indeed we are in the process of moving
documentation to the new website, so the links have changed. Old
website is available at wiki.flashrom.org address.

In your case, for overall dev guides, new link is:
https://www.flashrom.org/dev_guide/development_guide.html
Instructions how to add new chip hasn't been migrated yet, you can
access them by the link:
https://wiki.flashrom.org/Development_Guidelines#Adding/reviewing_a_new_flash_chip

Feel free to reach out if you have any more questions along the way.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom meeting notes 03.08.2023

[Anastasia Klimchuk]

# 3th August 2023, 6.00-7.00am UTC+0

Attendees: Stefan, Carl-Daniel, Anastasia

## Decision summary

* 3 developers get submit rights: Joursoir (Alexander Goncharov),
Peter Marheine, Nikolai Artemiev
* document the process of getting commit rights and send for review (todo aklm)

## Agenda

* [aklm] I would like to nominate 3 developers to get submit rights:
Joursoir (Alexander Goncharov)
[authored](https://review.coreboot.org/q/owner:c...@joursoir.net),
[reviewed](https://review.coreboot.org/q/reviewer:c...@joursoir.net),
Peter Marheine 
[authored](https://review.coreboot.org/q/owner:pmarhe...@chromium.org),
[reviewed](https://review.coreboot.org/q/reviewer:pmarhe...@chromium.org),
Nikolai Artemiev
[authored](https://review.coreboot.org/q/owner:nartem...@google.com),
[reviewed](https://review.coreboot.org/q/reviewer:nartem...@google.com).
They all made valuable contributions to flashrom, are on the project
for a while already: 1-2-3 years, currently active, are respected
members of the dev community.

To be more specific, and formal: we now have the duties documented
[https://www.flashrom.org/about_flashrom/team.html](https://www.flashrom.org/about_flashrom/team.html)
and all of them agreed to do the duties.

* all approved!
* [aklm] ongoing item: "We need to figure out criteria to give people
submit rights." Is it done with the Team page describing duties? A
missing piece is to describe the process (which currently is: someone
nominates you and adds an item to the meeting agenda in advance.
whoever comes to the meeting, discusses and decides). So maybe
document the process and ongoing item solved?
* yes, document the process, send for review (todo aklm)
* we can remove ongoing item
* the process can be improved later, if any issues are observed.
As of today, the process has been working for >1yr, everything seems
to go well.
* [Carl-Daniel] subject line for meeting notes email says "dev
meeting", but there are various questions discussed, not only dev, but
also organisational and any misc stuff.
* [aklm] we can drop "dev"? that would be "flashrom meeting notes
DD.MM."
* sounds good, drop "dev" from subject line

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: New flashrom website

[Anastasia Klimchuk]

Hello,

Redirect was on the plan, let me check about it.

Emergency help message: can you send a patch? That would be great!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Code of Conduct process (was: Re: flashrom dev meeting notes 20.07.2023)

[Anastasia Klimchuk]

Good Day,

> We have the friendliness document
> which serves as a sort of Code of Conduct.

It does not serve though.
Code of conduct is meant to protect members of the community from
unacceptable behavior, and Friendliness failed to do that.

Friendliness doc definitely has lots of potential and can be upgraded
to code of conduct. But this needs more work, which means more time.
>From your posts, my understanding is that you would like a discussion
on the mailing list. Don't know if you count this thread as it, or
perhaps you consider creating another one - but either way, some more
time for discussion.

> Why would we use coreboot's code of conduct as interim solution?
> You are proposing to establish a new foreign rule immediately (quoting
> your mail: "today")

Foreign? coreboot is foreign? You can't be serious! :) All of the
servers and infrastructure are coreboot's. This mailing list we are
talking right now, Gerrit, both old and new websites, etc etc, all
hosted on coreboot's servers. There are no "flashrom servers''. And
the majority of the people in the community overlap.

and oh, "today" meant "when patch is merged", not an exact date.

Yes, I would like to have an interim solution while we get to the full
solution, because having no solution at all is not great.

If it helps you: migrating Friendliness as is to the new website was
my first idea, and I started looking at it. I got to my computer with
the goal to create a patch to migrate friendliness. But when I
inspected the page closely, I realised there are lots of things to do
and it's not that trivial. Especially if the goal is to upgrade it to
be code of conduct. So instead I created a patch with what you called
"interim solution", which probably is an interim solution indeed, and
put a commit message explaining that.

>  I experience strong cognitive dissonance when matching
> your surely positive intentions with your actions. Please help me
> understand you.

Yes sure I can help!
Yeah, there was no link to the old website. I just added it and sent a
patch. I even recall at some point thinking "we need a link to wiki on
the menu" but I guess I wasn't on the computer at that time and by the
time I got to it I forgot :D

Oh actually I noticed you have an eagle eye for the new website. This
is very useful! I already fixed a few things that you shared on the
mailing list: like a broken contact link in readme and link to wiki.
But, absolutely don't hesitate to send a patch if you notice something
to fix. That would be very helpful.
https://www.flashrom.org/how_to_add_docs.html

> Because I started them. I would have expected you as a project leader to
> start those mailing list threads with a subject including "code of
> conduct" or similar.

A reminder: you learned about what is happening from the mailing list.
>From *my* post on this mailing list ;) That's the whole point of
sending meeting notes to the mailing list: everyone can read, everyone
who is interested can react.

Of course you can create new threads! You are welcome to create new
threads, with any important topics.

> I think the gerrit code review platform is the wrong
> place to discuss non-code policy.

I assume by saying "discuss" you mean people reacting and
posting/commenting. I see in the gerrit patch there are 6 people
actually discussing (adding comments). In the mailing list, it's just
us two talking.
As for reading: everyone can do reading, all the 389 subscribers are
reading. And I posted the gerrit link twice, for anyone interested. In
Gerrit: you can read all comments without even an account in gerrit.
Even our parents and kids can read those comments. And maybe they do
it right now :)

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Code of Conduct process (was: Re: flashrom dev meeting notes 20.07.2023)

[Anastasia Klimchuk]

I see. I think commit message to the patch gives an answer to your
question, I will copy commit message here just in case you maybe
missed it:

> 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.

It can take some time to produce our own code of conduct, and yes now
we have 3 threads on the mailing list, and maybe we'll have even more.
Meanwhile, between today and the time we finish our code of conduct,
we can use coreboot's one.

There is no demolition, if you look at the patch it adds a new page
and does not remove anything. Also as I said we now have 3 threads on
the mailing list. So... I am not entirely sure whether your reference
applies. But now I know what your favorite book is :)

Also for anyone who is reading this post and is interested to click
the link: here it is, welcome!
https://review.coreboot.org/c/flashrom/+/76455

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: flashrom dev meeting notes 20.07.2023

[Anastasia Klimchuk]

Carl-Daniel,

Thank you so much for your message! I know you don't post to the
mailing list often, I appreciate you took the time to do this!

Of course I want flashrom to be a safe place for everyone. And
everyone else wants this too!

You are very welcome to send a patch to convert the Friendliness wiki
page to our new sphinx docs, so that it can be added to the new
website. You haven't mentioned any specifics in your message: who were
the people you worked with, which problems were you solving, and which
common codes of conducts were taken as examples. But I am sure you
would incorporate all that in your patch.
Also of course, please add everyone who is interested to the patch.

Few things I would mention from my side. I was actually looking
closely at the Friendliness page recently. It seems unfinished, there
is a todo in the middle (sitting there from 2009). Some parts of it
belong to the Development guide, and could be updated there, if needed
at all. Some other parts can be better placed on the Contacts page. It
would be great if you can incorporate all that in your patch.
In any case, send a patch, add reviewers and then we will have a look!

About Code of Conduct: this is established and standard terminology,
and a project needs one. However the content is in our hands, and this
is exactly why there is a patch now under review. People are already
reviewing, adding comments, and you are very welcome to add your
comments as well.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: upgrading Development guidelines on the next meeting 27th Apr

[Anastasia Klimchuk]

Update: this is now live!
https://www.flashrom.org/dev_guide/development_guide.html

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: New flashrom website

[Anastasia Klimchuk]

And now,

New website is live!
Thanks heaps to Thomas, Stefan, Patrick, Peter, Joursoir, me, and
everyone else who did code reviews and supported the effort in any
other way! <3

flashrom.org is the new website

wiki.flashrom.org is officially the old one, and it is already locked
for editing (still fully available in view-mode).

>From now on, to add or update documentation you need to send a patch.
And everyone is very very welcome to do so!

Relevant docs:
How to add or update docs: https://www.flashrom.org/how_to_add_docs.html
Development guide: https://www.flashrom.org/dev_guide/development_guide.html

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 20.07.2023

[Anastasia Klimchuk]

# 20th July 2023, 6.00-7.00am UTC+0

Attendees: Stefan, Edward, Anastasia

## Decision summary

* flashrom.org is new, wiki.flashrom.org is old (will be a dedicated
post on the ML)

## Agenda

* New website: let's do it right now!
* Done: flashrom.org is new, wiki.flashrom.org is old, and old one
is locked for editing (no edit button anymore)
* one thing left: put a red banner on old wiki which says it is
retired and locked for editing
* aklm to post news on mailing list
* Code of conduct patch
[https://review.coreboot.org/c/flashrom/+/76455](https://review.coreboot.org/c/flashrom/+/76455)
* maybe coreboot can help in the beginning? but longer term we need our own.
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 22.06.2023

[Anastasia Klimchuk]

# 22th June 2023, 6.00-7.00am UTC+0

Attendees: Stefan, Edward, Anastasia

## Decision summary

* More documentation coming soon, patches will be sent for review (see below)

## Agenda

* License for docs, do we just create a page with license text like
coreboot? 
[https://doc.coreboot.org/documentation_license.html](https://doc.coreboot.org/documentation_license.html)
* 
[https://review.coreboot.org/c/flashrom/+/75727](https://review.coreboot.org/c/flashrom/+/75727)
is this page sufficient ?
* do we need to mention license on every page, e.g. in the footer?
>> probably not
* 75727 should be sufficient, aklm needs to finish that patch ->
and then we can swap websites -> lock wiki for editing, with a banner
on the top
* after swapping websites, we can add a redirect, if someone is
following the old link. If the page is not found on new website (could
be that it hasn't been converted yet) -> auto-redirected to
wiki.flashrom.org
* [aklm] "flashrom developers" group needs to be up-to date
* responsibilities for the members of the group? need to be
documented >> TODO aklm
* also document responsibilities for "flashrom reviewers"
* members list should be up-to-date: whoever is doing the duties
* we need a code of conduct. can we adopt coreboot's one? >> yes
* needs to be documented, add a page on the website >> TODO aklm,
send a patch for review
* Friendliness is also a nice text, can go together, also needs to
be on the [new] website >> convert to rst and send a patch.
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: upgrading Development guidelines on the next meeting 27th Apr

[Anastasia Klimchuk]

Update: this has progressed into a patch under review
https://review.coreboot.org/c/flashrom/+/75906

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Patch for Macronix MX77L25650F

[Anastasia Klimchuk]

Hello, thank you for the patch!
There is currently a patch under review adding the same chip:
https://review.coreboot.org/c/flashrom/+/68557
Do you have a Gerrit account? If yes, you can add yourself to the
patch and watch the progress. If not, just check the link.
I see your patch has more, so the end result would probably be
combining the two.

In general, we do code reviews in Gerrit (not the mailing list). Even
if you send a patch on a mailing list, someone needs to push it to
Gerrit to continue.
Another thing is: commit message required to have a Signed-off-by line.
You don't need to push this patch (since there is already the same
chip under review), but for future if you would try to push to gerrit
next time, that would be great!

https://www.flashrom.org/Development_Guidelines

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Some flashrom issues reported and a couple of patches

[Anastasia Klimchuk]

Leonard,
Thank you so much for your ideas and patches! Will have a look at these.
As for signing off the patches, we recently updated the policy (in the
same way as Linux did) so now it doesn't have to be a real real name.
However it still needs to be a known identity, for example if everyone
knows you by the nickname that's fine.
If at any point in future you decide to send a patch for review from
yourself, you are very welcome.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Unable to build flashrom from git repo without sphinx

[Anastasia Klimchuk]

I really like how we collectively debugged the issue and identified
the root cause, even without Alex responding. This is so cool, thanks
everyone! <3

Alex,

Yes it's true that makefile will be deleted soon, probably later this
year. It's a very good time to switch to meson, and please complain if
anything doesn't work for you, feedback is very welcome.

The first few paragraphs of README "Build Instructions" introduce
meson and redirect to the documentation at /Documentation/building.md.

Also because documentation is active WIP at the moment, after patch
https://review.coreboot.org/c/flashrom/+/73359 will be merged, it will
be moved to doc/dev_guide/building_from_source.rst

I admit those first few paragraphs of README (which I added in
December 2022) have room for improvement. Also the whole README has
room for improvement, and we are planning to take care of it soon.

I noticed you complained about

> It doesn’t seem possible to cleanly build flashrom without installing a TON 
> of dependencies

Some of the dependencies are optional and only needed if certain
programmers are needed. But I feel maybe you got grumpy at
sphinx-build and it was the last straw.
As I mentioned before, if you build with meson, sphinx-build is
optional. All the docs in doc/ directory are in .rst format which is
easily readable by the human eye, so fetching the source code will be
sufficient to read the docs.

And of course, you are always welcome to send a patch.
Good luck and tell us how it goes!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Unable to build flashrom from git repo without sphinx

[Anastasia Klimchuk]

Hi Alex,

This is definitely not intended behaviour: sphinx is optional. If it
is not present, flashrom can be built, just without docs.
I didn't have sphinx locally for a while, and was building the sources
without it. Only installed it very recently, because I started to add
docs.

Can you tell exactly how you are building? Logs maybe? I want to help.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 22.03.2023

[Anastasia Klimchuk]

# 22th March 2023, 21:00 - 22:00 UTC+0

Attendees: Thomas, Stefan, Edward, Prakhar, Anastasia

## Decision summary

* We need to update Signed-off-by guidelines , like Linux kernel did
recently: strict real names not required to sign-off, can be a
preferred known nickname (but not anonymous). DONE
* REMINDER season changes: next meeting in 3 weeks, 13th April 6.00-7.00am UTC+0

## Agenda

* [Stefan] I know we have this as an ongoing item, and I would like to
bring the flashrom leadership situation up for  discussion. I would
like to nominate and ask Anastasia to run the project. Let’s discuss.
* Everyone present +2 the nomination.
* AI: Stefan to reach out to maintainers + Angel individually
before mailing list [April 4: done]
* [Thomas] Update Signed-off-by guidelines based on new linux kernel
developments and clarifications.
[https://github.com/torvalds/linux/commit/d4563201f33a022fc0353033d9dfeb1606a88330](https://github.com/torvalds/linux/commit/d4563201f33a022fc0353033d9dfeb1606a88330)
* TODO aklm to update this bit in current dev guidelines
* REMINDER season changes: next meeting in 3 weeks, 13th April 6.00-7.00am UTC+0

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Reminder: flashrom meeting time changes to 6.00 UTC+0 from April

[Anastasia Klimchuk]

Hello everyone,

Just a reminder that from April and until September flashrom meetings
move to Thursday 6.00-7.00am UTC+0
Next one is 13th April 6.00-7.00am UTC+0, and then every two weeks as usual.

More details here https://www.flashrom.org/Contact#Dev_meeting

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flash of [Winbond flash chip "W25Q128.V"] with Programmer [ch341a_spi]

[Anastasia Klimchuk]

Thank you! I just checked, the chip marked tested on head, so it
should go to the next release. Good to have confirmation that it
works!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: logs for GD25Q256D on raspberry pi 1B

[Anastasia Klimchuk]

Adam, thank you!
I looked at your logs, it seems like you are running not the latest
version (1.2 in the logs vs 1.3 is the latest). In the latest version,
this chip is marked as tested.

But thank you anyway! :)

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 08.03.2023

[Anastasia Klimchuk]

# 8th March 2023, 21:00 - 22:00 UTC+0

Attendees: Thomas, Prakhar, Anastasia

## Decision summary

* We will be using CreativeCommons license for documentation, CC-BY-4.0
* 26th April on this meeting will be a “development guidelines
brainstorming session”. Everyone with ideas on how to improve
development guidelines is welcome to join.
* 3 weeks break for meetings between 22th March and 12th April. And
then every 2 weeks as usual.

## Agenda

* [aklm] We wanted to have a “development guidelines brainstorming
session” after the release. Seems the time has come? We can allocate
the next meeting for this? Or maybe the next meeting in April,
depending on who wants to join.
* Yes we can do it on 26th of April. We can create a doc for
brainstorming, and everyone will edit it. Once the text is composed,
then it can be added to documentation.
* [Thomas] How should we license the new documentation? GPL /
CreativeCommons / something else
* GPL is optimised for code/software
* and then CreativeCommons is for everything, not just code/software
* what is the level of CreativeCommons license that would be
equivalent to what we have now? CC-BY -> do everything that you want,
but have to name the original authors.
* 
[https://doc.coreboot.org/documentation_license.html](https://doc.coreboot.org/documentation_license.html)
coreboot has different license for code vs documentation.
* that would enable people to write a tutorial based on new docs.
* Do we need to add a line to every doc?
* (..|//| #) SPDX-License-Identifier: CC-BY-4.0
* we can add git hook to check for this one line
* The one-line can be used for code too, with the existing license.
Would save repetition of the same text in every file.
* [aklm] can we do a 3 week gap between the last meeting in March and
first in April? and then 2 weeks as usual.
* Yes, we will have a meeting on the 22nd of March as usual, and
then 12th April, and then every 2 weeks as usual.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Release schedule

[Anastasia Klimchuk]

Good Day flashrom,

We had an important decision about flashrom release schedule recently,
and it went to the mailing list as a part of dev meeting notes
(22.02.2023). However, the topic is big enough to have a dedicated
thread on the mailing list.

We decided to make releases twice a year: one in spring/autumn, and
another one in autumn/spring. The idea is that no one has to make a
release in summer.

Specifically, the plan is to have two release windows per year, the
duration of a window is 3-4 weeks (4 weeks max hard limit):
end of April-May
end of September-October

What is happening during release window:
#1 No new features merged
#2 Active testing and bug fixing
#3 Bug fixes patches are really welcome, and are merged
#3 If the bug is critical and release blocking, it either needs to be
fixed or code needs to be reverted.

Just to be clear: release window meant to be fixed (3-4 weeks) and not
extended, because that will be effectively a "feature freeze" window.

At the end of the window, we put a release candidate tag and make a
release branch. If later a point release is needed, it goes to the
branch.

Specifically, what does it mean for this year: if you are planning to
contribute a patch/feature/bugfix, you have time until mid-April to
get into 1.4 release. If not, then you have time until mid-September
to get into 1.5.

Having said that, this is the first year we are trying to have a
release schedule and it is possible that during this first year we
will learn some lessons and then adjust and improve :)

Also, there is a page on the website about the release process, but it
is out of date at the moment. It will be updated later with all the
info.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: AM29LV040B writes work fine

[Anastasia Klimchuk]

I have created a patch for this chip:
https://review.coreboot.org/c/flashrom/+/73429

Alex, do you have logs from that successful write that you did?
And also, I still think it would be a good idea to create a gerrit
account, to be able to send or review a patch one day! ;)

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: AM29LV040B writes work fine

[Anastasia Klimchuk]

Alex, thank you so much for the report!
I have a question for you: do you think you can send a patch to
flashrom, to mark AM29LV040B as write-tested? That would be so great!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: manpage and documentation

[Anastasia Klimchuk]

Thomas this is fantastic, thank you so much! Sorry that it took me so
long to respond.
And that it can help with migrating and upgrading the
homepage/website, make it even better!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 22.02.2023

[Anastasia Klimchuk]

# 22th February 2023, 21:00 - 22:00 UTC+0

Attendees: Thomas, Stefan, Prakhar, Anastasia

## Decision summary

* New flashrom home page generated with sphinx coming soon. And then
we eventually move relevant content from wiki and deprecate wiki.
Details below in notes.
* We will have two release windows per year: one in spring/autumn and
one in autumn/spring. For this year, we are trying the approach,
planned windows are end of April-May and end of September-October. The
size of a window is 3-4 weeks, during that time we have feature freeze
and only bugfixing. At the end of the window, tag the release and
create the release branch.

## Agenda

* Patches to support Power PC coming, Stefan will help with testing
* [quasisec] 
[https://review.coreboot.org/c/flashrom/+/70264](https://review.coreboot.org/c/flashrom/+/70264)
needs attention. Same for
[https://review.coreboot.org/c/flashrom/+/67481](https://review.coreboot.org/c/flashrom/+/67481)
and 
[https://review.coreboot.org/c/flashrom/+/67480/](https://review.coreboot.org/c/flashrom/+/67480/)
* It would be good to trim the tree’s verbosity down more and make
things more consistent too.
* Seems all good, TODO Thomas will have a look and also approve.
Patches need to be rebased, hopefully for the last time.
* [quasisec] 
[https://review.coreboot.org/q/topic:gsoc](https://review.coreboot.org/q/topic:gsoc)
needs help from the community as a whole to help light get his work
merged. I did quite a bit of patch review but more help is needed.
GSoC work shouldn’t be left endlessly in review with an all or nothing
approach.
* As of today, this is merged.
* Announcement to the mailing list coming soon (TODO Aarya)
* [quasisec] new flashrom website, what is the timeline to get it up
and running? It has been half a year since we confirmed the objective
to do it.
* Home page now can be generated with sphinx
* 
[https://review.coreboot.org/c/flashrom/+/72619](https://review.coreboot.org/c/flashrom/+/72619)
* The Plan
* Sphinx patch needs to be merged
* Build instructions integrated into sphinx, as a separate page
* README context needs to be upgraded, as a landing page
* Create CI to render sphinx to subdomain. Subdomain could be
for the first few iterations for testing. Could be new.flashrom.org
* Switch new page to flashrom.org, old stuff goes to wiki.flashrom.org
* Migrate pages one-by-one
* Eventually deprecate wiki
* [aklm] let's decide when do we do 1.4? 1-2 months window maybe, some
time later this year?
* Maybe we decide on a window for each year, and stick to that?
Two windows, even better. If necessary, point releases in between.
* We can have two releases per year: one in spring, one in autumn.
Below is suggested plan:
* Next window is at the end of April-May. We can tag rc1 on
17th or 24th April, and for the following 4 weeks we have feature
freeze, but actively bugfixing.
* Every week we tag rc+1.
* After 3-4 weeks we tag a release. At this point make a branch.
* If something is discovered to be unfixable in this time, and
no one is interested to fix, revert it.
* Second window could be around the end September - October
(exact dates TBD later).
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 08.02.2023

[Anastasia Klimchuk]

Apologies for the delay, these are notes from two weeks ago.

# 8th February 2023, 21:00 - 22:00 UTC+0

Attendees: Thomas, Stefan, Prakhar, Anastasia

## Decision summary

* Few upgrades for Easy Projects page (TODO aklm)

## Agenda

* [aklm] Easy Projects page needs some love.
* How about “Write a unit test” as an easy project? -> aklm will add on wiki
* Thomas: we can have a topic for easy projects, and contributors
can look for existing patches for a topic. For every section in easy
projects a separate topic, for example “easy_project_scan_build”,
“easy_project_unit_test”.
* Maybe a small guide how to set a topic in gerrit
* One more section: link to bug tracker with Easy Projects category of bugs.
* Thomas: after removing the makefile, let’s make more targets
default. Debug build can have everything. At the moment build options
are the same, but after dropping makefile we can set meson default
options
* Thomas: Use meson subprojects for dependencies on cross compile targets
* Convert README to restructured text as in the patch
[https://review.coreboot.org/c/flashrom/+/72619/](https://review.coreboot.org/c/flashrom/+/72619/)
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom release v1.3.0 is out

[Anastasia Klimchuk]

Good Day flashrom community,

flashrom release v1.3.0 is out!

Tag name: v1.3.0
Branch name: 1.3.x
Tarball: download.flashrom.org/releases/flashrom-v1.3.0.tar.bz2
Signature: download.flashrom.org/releases/flashrom-v1.3.0.tar.bz2.asc
Fingerprint: 6E6E F9A0 BA47 8006 E277  6E4C C037 BB41 3134 D111

I will create a new page on the website for 1.3.0 very soon (will
respond to this thread with a link).

Main reason why it will take some extra time to create a page is
because I need to try and list all important changes since v1.2 which
was 3 years ago.
There is a high-level overview of changes in the earlier announcement
about the first release candidate for 1.3, but I am hoping to create a
more detailed list for the website page.

Many thanks to everyone who contributed to the release: testing
flashrom, sending and reviewing patches, discussing and triaging bugs,
branching and tagging, signing and uploading the tarball, and
supporting each other along the way. 1.3 has happened because we did
it together as a cool team!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 25.01.2023

[Anastasia Klimchuk]

# 25th January 2023, 21:00 - 22:00 UTC+0

Attendees: Thomas, Stefan, Prakhar, Nico, Edward, Anastasia

## Decision summary

* Flashrom is not applying as a mentorship organisation for gsoc 2023
(no capacity to do all admin work, tight timelines). Independent
contributors (outside of scope of gsoc) are always welcome as usual!
* Several improvements for README file on the way (TODO aklm)
* We will be implementing the versioning for meson (Thomas)
* We grow MAINTAINERS file and then add people from there into
“flashrom reviewers” group (add those who agree, ask before adding)
* Flashrom-stable will have a menu item on the left-side menu on the
wiki, and a section on the bottom menu on the wiki home page

## Agenda

* [aklm] Looks like we are not doing gsoc in 2023 :(
* A lot of things to do: project ideas list, mentors, easy starter
projects, review development guidelines. Aklm has less capacity than
last year, and no one available to help.
* Timeline has shifted for earlier,
[https://developers.google.com/open-source/gsoc/timeline](https://developers.google.com/open-source/gsoc/timeline)
and now the window for organisations to apply is from January 23 -
18:00 UTC until February 7 - 18:00 UTC.
* If we do this year, two things to do ~now are: [project
ideas](https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs4qIs/edit#heading=h.4qf023w062ha)
list and mentors. Can we do it now? NO.
* Instead of gsoc 2023 , we will do the following:
* Complete last year project, and merge (Aarya)
* Continue One build system work, make it actually one
* Second iteration of erase/write optimisations, we can
combine the best of two worlds: take the best of two algorithms from
upstream, and chromium tree and have one algo which performs great in
both trees
* [aklm] Updating README file, technically can be done any time, when
do we want to do this, and who is interested to brainstorm new README
?
* Packaging section needs an overhaul, currently only make is
supported. So the packaging can only be done with make. When packaging
is done with meson, version info is missing.
* Add one sentence into Packaging, info from previous point (TODO aklm)
* Re-order sections: Build instructions, Installations, Packaging,
Contact (TODO aklm)
* Fix `http` -> `https` in README, all the links (TODO aklm)
* Rename with `.md` suffix? Reformat with markdown (TODO aklm)
* Thomas: Versioning: we need to introduce versioning file - as meson
disk tree image does not contain the `.git` directory and so cannot
easily harvest the version information. Therefore we need to generate
a header with the current version to be included in the build.
* 
[https://github.com/Mesa3D/mesa/blob/main/meson.build#L25](https://github.com/Mesa3D/mesa/blob/main/meson.build#L25)
(out of date, now using a ‘VERSION’ file)
* 
[https://github.com/Mesa3D/mesa/blob/main/bin/meson_get_version.py](https://github.com/Mesa3D/mesa/blob/main/bin/meson_get_version.py)
* When doing a release, create a commit into the version file to
increase version number. And then put a git tag linked to this commit.
* When versioning is solved, we will have a larger upgrade to README file.
* Thomas: for scripts we need to move to python, we get python
environment with meson. Easier for different environments.
* [aklm] Gerrit groups “flashrom reviewers” and “flashrom developers”.
* Flashrom reviewers is the gerrit group which can approve patches
(+2) but cannot submit. At the moment there is none, only very large
coreboot group. Not all people who work on coreboot work on flashrom.
* aklm : lets build MAINTAINERS file and then add those people
into “flashrom reviewers” group. Reason: people agreed to do code
reviews for a specific area of flashrom, and they have knowledge of
that area. They need to be able to say “yes I approve this patch”.
* Thomas: we could have someone who is not in MAINTAINERS file,
but we may want to add them to flashrom reviewers group.
* Aklm: there are no technical restrictions on that, but we need
to publish clear criteria on when a person who is not in MAINTAINERS
file can be in reviewers group.
* Lets think of criteria and return back to this question.
* [icon] could/should flashrom & flashrom-stable share resources like
the webpage / wiki?
* We can add a menu item on the left-side menu, and/or a section
in the bottom menu on the home page. Lets see how it goes, if there
will be any issues we will discuss, but maybe it will just work. Nico
will add pages.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Second release candidate v1.3.0-rc2 and countdown to release

[Anastasia Klimchuk]

Hello flashrom community,

Second release candidate v1.3.0-rc2 (and likely the final one) has
been tagged. It includes the fix for int-to-pointer-cast warnings for
32-bit Linux.

Let's start the countdown until the end of January, and if no
emergency happens, we will cut the release.

I am copying below a piece from my previous announcement (since it
still might be useful)

How to report a bug or successful testing: there are few options.
First option is to post on the mailing list (feel free to reply on
this thread, or create a new thread).
Second option is to add a comment to a ticket "Testing for release
v1.3" https://ticket.coreboot.org/issues/378. This would require an
account in bugtracker (coreboot account is fine).
Thirdly, of course, you can fix a bug and send a patch! :) Please set
a topic "for_1.3.x"

Thank you!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: meson build failure on 32bit [linux]

[Anastasia Klimchuk]

Branden, I made a patch with that:
https://review.coreboot.org/c/flashrom/+/72038
If you could have a look and say whether this is what you have tested?
If you have an account in Gerrit you can approve the patch, if not you
can just reply here.

Would you like to be added as Tested-By tag? That would mean your real
name and email, if you agree on that.

Thank you!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: meson build failure on 32bit [linux]

[Anastasia Klimchuk]

Very good news, thank you for the update!

Would you agree to send a patch to Gerrit? Have you used Gerrit before?
I think you are the best person to send a patch, because you have the
environment, and you did the actual testing.

As a plan B I could send a patch and add you as Tested-By , and a code
reviewer. But the first option would be ideal, if this is possible?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: meson build failure on 32bit [linux]

[Anastasia Klimchuk]

Hello Branden,

First of all, thanks heaps for testing v1.3.0-rc1 and posting on the list!

I looked at the logs, it seems you have this issue which was
discovered some time earlier: https://ticket.coreboot.org/issues/407
The issue has been reported on the #flashrom irc channel, and
potential solution has been suggested by reporter (see the description
in the ticket).
I currently don't have a 32-bit Linux environment, so I haven't done
anything yet :\ But looks like you have an environment, would you be
able to test the fix ? That would be so helpful!
Maybe you will be able to send a patch? :) I am looking at the
proposed solution in the ticket, and it very likely will work.

The root cause of the issue is: warnings in unit tests when building
for 32-bit Linux. And since we enabled the mode "treat warnings as
errors", this fails the build.
As a workaround, you can disable Werror by running in your builddir:

meson configure -Dwerror=false

This option is sticky: if you run it once the mode will stay until you
enable werror again.

Another option is to build without unit tests, although it is less
ideal because unit tests are useful.

Initially we did not mark this bug as release blocking, since it can
be worked around relatively easily. But if you are able to send a
patch we will gladly accept it and cherry-pick into the release
branch!

Let me know what you think? In any case, many thanks for your effort!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: master state / potential release

[Anastasia Klimchuk]

The initial list of tickets for the release was created from Nico’s
list of issues to check before the release. (see earlier thread about
the release). Some of these are bugs, some others were in the form
“what do we do with this?”. I understand that since a few months ago
things could have changed, and if as of today we all look at the list
and we all feel like some of the tickets are not blocking release,
that’s fine. We can unlink them from parent 353 and just leave in
bugtracker as a ticket.

Re: bug vs feature and other fields. Please change to whatever you
feel is more appropriate. It doesn’t matter for me which type the
ticket has. Important info for me is parent ticket (or absence of it)
and clear description.

As I posted at that time on the mailing list in “Release preparations”:
> Surely all of the descriptions can be improved, or more info can be added to 
> issues. Especially if you are taking an issue and start working on it.

We can also go once again through the list and decide whether all the
remaining ones are indeed blocking. We can do this on 2rd November UTC
(next scheduled flashrom meeting).

> Even though we (Angel) are not licensed therapists, we are willing to listen 
> to you.
Angel, thank you so much! This is really nice of you! It is so
important to support each other.
I think I am fine. I am very lucky to have a great team at work, and
great upstream teammates!
But I am on the channel as usual :) Surely we will talk!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: master state / potential release

[Anastasia Klimchuk]

Nico what was the goal why you started this thread?

I thought for a moment, you have a *quick* question. So I answered.
Now you seem to be unhappy to learn that we are closer to the release
than 1/2 yr ago.
You are saying "But I don't believe you", what was the point of asking then?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: master state / potential release

[Anastasia Klimchuk]

Hello,

A quick answer first:
We are closer to the release, and the state of the master is better
than a half year ago.

More details.
In general, the progress is visible here https://ticket.coreboot.org/issues/353

There is one issue that came up around May
https://ticket.coreboot.org/issues/390 . This one is new. It does not
prevent from using any functionality, and also if the user does not
specify `--progress` they won’t even notice.

On the other hand, several issues have been fixed. Dummyflasher is
fixed, i2c programmers got allow_brick param and were improved.

Manpages are added to all programmers that were missing them (I think,
to all programmers, hopefully I am not forgetting anything).

Lots of code improvements: for example we have way less global state
than it used to be 1/2yr ago, and we have more unit tests of all
types.

Meson build file got a great upgrade. For this change I can mention:
it was merged into chromium flashrom ~2weeks ago and no issues
observed so far. Also there is now Documentation/ for how to build
with meson.

Surely there were more improvements. I am just listing what is on the
top of my mind.

If you ask me to pick what’s very important to fix I would say
https://ticket.coreboot.org/issues/370 I remember several patches on
that, from different people. Potentially, the bug is [technically]
fixed, but we need to coordinate who is rebasing on the top of whom,
and complete the review.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Question on adding some WP documentation

[Anastasia Klimchuk]

Hello Sergii,

To the question whether the documentation is useful: IMO Yes, I 100%
think it is useful. I did a quick read through the links.

Where to put it, this is an interesting question.

The advantage of Documentation/ directory in the repository is that it
allows other people (anyone who is interested) to review the text
before adding. Because for Documentation/ you basically send a patch
and everyone can review. End result gets submitted, and everyone is
happy.

For the website, there is no review mechanism, so you either update
the page and announce it to everyone, and then people can make
corrections post-update. Another way is, after preparing the text you
send it to the mailing list and gather feedback, and then later
incorporate feedback into the final version of text.
This is a more awkward process. But as you said, these docs are for
users not developers - so the website seems like a more logical place.
I looked through the website, this section seems relevant:
https://www.flashrom.org/Documentation#Using_flashrom ?

For the website also, we do have ideas to dramatically upgrade it, but
in any case all the content will be migrated over.

I am wondering what other people think, especially if anyone has
strong opinions on Documentation/ vs wiki?

On Sat, Oct 8, 2022 at 8:41 AM Sergii Dmytruk  wrote:
>
> Hi there,
>
> We have a bit of user documentation that shows how to lock a bootblock using
> WP [1] and what should be taken into account before you do it [2] and
> thought we can offer it to the upstream (after a bit of editing if there
> is interest).
>
> [1]: 
> https://github.com/Dasharo/flashrom/blob/wp_integration/Documentation/heads-and-wp.md#risks-of-partial-updates
> [2]: 
> https://github.com/Dasharo/flashrom/blob/wp_integration/Documentation/bootblock-protection.md
>
> There is Documentation/ directory in the repository, but I guess Wiki on
> www.flashrom.org might be more appropriate as it's not documentation for
> developers.  The current format is Markdown, but `pandoc` can convert the
> files to MediaWiki without issues.
>
> Please check out the docs and say if they can be useful for the project.
>
> Cheers,
> Sergii
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: GSOC'23

[Anastasia Klimchuk]

Hello Prakhar,

Thank you for your introduction!

> I am new to the open source world and I will be trying for GSOC'23.

For the program year 2022 (which is wrapping up already) we made a
page with guidelines for contributors: https://www.flashrom.org/GSoC
Most of the information is still relevant, so you can definitely start there.
We will be improving the page around the end of year, to prepare it for 2023.

Good luck!
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Maybe move dev meeting from 22 Sept to 23 Sept?

[Anastasia Klimchuk]

Okay looks like people either fine or don't care (no one is against),
so non-negative response.
Let's move to 23 Sept then. I will modify the event, so that will be
an email generated with "Updated invitation".
Thanks everyone!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Maybe move dev meeting from 22 Sept to 23 Sept?

[Anastasia Klimchuk]

Hello,

The next dev meeting is scheduled for 22 Sept, but it turns out there
are some things happening:

1) This is a day right after OSFC which many people are attending.
Joining a meeting early in the morning right after the last day of
conference, from a hotel room, is not ideal.

2) All of a sudden, AU got a [one-off] public holiday on 22 Sept
(National Day of Mourning)

With all that, an idea is to move the meeting one day forward, 23
Sept, the same time.
What do people think?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Introduction to the community - Dhiren

[Anastasia Klimchuk]

Hi Dhiren,

> the idea about bash auto completion sounds interesting to me and I would like 
> to work on it
Awesome! You are in :)

> Do you recommend to first play more with flashrom and then work on this 
> feature?
Yes, I recommend to do few small things first. For example, this is
one more easy project that we created just recently:
https://ticket.coreboot.org/issues/416 (in addition to
https://ticket.coreboot.org/issues/405 that I mentioned previously).
If you want you can create an account on bug tracker and then you'll
be able to assign ticket(s) to yourself!

The reason is that auto completion is meant to cover most often used
commands. Ideally you would use flashrom by yourself for some time,
and then you will have a much better idea what are most often used
commands.

Good luck!
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Introduction to the community - Dhiren

[Anastasia Klimchuk]

Hello Dhiren, and welcome!

I know you got lots of advice on the irc channel (which is great), I
wanted to add a few more things to that.

> I'm not a student anymore I cannot do it as part of GSOC, but I have done 
> open source contribution since 2 years

That "student" requirement has been taken off gsoc starting from 2022,
so non-students can join gsoc too. However, the requirement now is to
be a beginner to open source, and not to have significant previous
contributions to open source projects. Depending on what you have been
doing for 2 years, you may or may not pass through the "beginner"
requirement.
Also gsoc has a very specific timeline and week-by-week schedule and
commitments, so it might be easier to do something in your own time
(as a hobby as you said) independently of gsoc.

Speaking about starter projects, in addition to what people advised on
the irc, there are issues in our bugtracker in the category "Easy
Projects" which you can look at. This one as an example
https://ticket.coreboot.org/issues/405
Also this https://www.flashrom.org/Easy_projects#Fix_issues_found_by_scan-build
but I think you saw that already.

Another idea that came up just recently was to implement bash
completion for flashrom command line. Tell us if you are interested.

Speaking about
> Design and implement new CLI based on libflashrom and extend the API as 
> necessary

This was in the list for 2022, and we will be reviewing the list at
some point. I am not entirely sure what the current status of this
project is.
But in any case there are lots of things for you to "get some hands
dirty in Linux world" as you said :)
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom maintainers

[Anastasia Klimchuk]

Hello People,

We just got a flashrom’s own MAINTAINERS file! I wanted to share the
news with everyone.
https://github.com/flashrom/flashrom/blob/master/MAINTAINERS

There is a script which will automatically add people as reviewers to
the patch, if the patch is touching the files/area they are
“registered” for. This makes sure patches are not lost and also
answers the question “who are the best reviewers for this patch?”
Anyone else can join any code review (as usual, as it was before), but
the people from the file will be added automatically.

Is anyone interested in being a maintainer/reviewer? Maybe you know
some specific area well, and/or maybe you don’t want to miss when a
patch comes along and touches that area.
“Area” can be just one programmer that you know well, and you can take
it with “Odd Fixes” status - this is the smallest possible commitment,
but still will be very useful for flashrom.

Any area can have multiple maintainers.

Also, MAINTAINERS file have some content already, but you can of
course join the existing category if you are interested.

What to do if you are interested? You can reply to this thread or just
send a patch.

I have some thoughts on what categories/areas we can have, but that’s
my initial suggestion, it is not a complete list and everyone’s ideas
are welcome.

Many thanks!

# Programmers

In general, one programmer can be a category by itself. Some others
can be grouped (for example we have an i2c group with 3 items).

# Libflashrom (can be sub-category of Core)

libflashrom*
include/libflashrom*

# Documentation

Doxyfile
README
flashrom.8.tmpl

# Core

Flashrom.c
Layout.c
Jedec.c
Opaque.c
Spi.c
Programmer.c
Programmer_table.c
Spi25.c
Spi25_statusreg.c
Spi95.c
… and more files here, and headers

# internal

List of files here, also headers

# Configs

MAINTAINERS

# Git (can be sub-category of Configs)

.gitattributes
.gitignore

# Scripts

*.sh
util/*.nix
util/*.sh

#CLI

cli*

# Utils

Manibuilder
Flashrom_tester
ubertest

# Flashchips

flashchips.c
One file, but it has a constant stream of patches. Would be great to
have someone keeping an eye on it.

# Tests

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flash tested

[Anastasia Klimchuk]

Hello! Good to know the chip is working, If you can send logs that
would be great! Thank you.

On Sat, Jul 9, 2022 at 2:56 AM Tygert Baggins  wrote:
>
> Hello,
> I builded flashrom from source (2022-07-02) on Odroid C4 board (raspberry 
> clone) and tested flash chip FM25F01, everything was working perfectly with 
> spispeed=1000. Do i need to send some screenshots?
> Thanks for great tool.
>
> --
> Adam Mielewczyk
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] flashrom dev meeting notes 30.06.22

[Anastasia Klimchuk]

# 30th June 2022, 6:00 - 7:00 UTC+0

Attendees: Edward, Thomas, Stefan, Nikolai, Anastasia, Felix

## Decisions Summary

* Raiden_debug_spi: Thomas will do a review of this programmer and add
comments to the bug
[https://ticket.coreboot.org/issues/358](https://ticket.coreboot.org/issues/358)
* As a result of in-depth discussion of lspcon_i2c_spi and
realtek_mst_i2c_spi a bunch of bugs will be created (TODO for aklm).
Some of them have wider scope like infra improvements.
* Sb600spi work has started and needs reviewers attention
* 
[https://review.coreboot.org/c/flashrom/+/65237](https://review.coreboot.org/c/flashrom/+/65237)
* 
[https://review.coreboot.org/c/flashrom/+/65238](https://review.coreboot.org/c/flashrom/+/65238)
* 
[https://review.coreboot.org/c/flashrom/+/65239](https://review.coreboot.org/c/flashrom/+/65239)

## Agenda

* [aklm] Bugs for release “document this programmer”. Is there
anything left to do, if yes then what is left?
* 
[raiden_debug_spi](https://github.com/flashrom/flashrom/blob/master/raiden_debug_spi.c)
 
[https://ticket.coreboot.org/issues/358](https://ticket.coreboot.org/issues/358)
(man page and code comments added -
[https://review.coreboot.org/c/flashrom/+/62768](https://review.coreboot.org/c/flashrom/+/62768))
* Docs 
[https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/servo_v2.md](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/servo_v2.md)
* Thomas will review raiden_debug and add all comments to the bug
* AI(quasisec) work with Tools team to document the hardware schematics
to make it easier to find and nativage by putting all the
docs in one place.
* AI(quasisec) file bug to convert init code so that usb vid:pid pair
are in the deventry. Basically FIX the FIXME in
[https://github.com/flashrom/flashrom/blob/master/raiden_debug_spi.c#L352](https://github.com/flashrom/flashrom/blob/master/raiden_debug_spi.c#L352)
and remove lines
[https://github.com/flashrom/flashrom/blob/master/raiden_debug_spi.c#L1501](https://github.com/flashrom/flashrom/blob/master/raiden_debug_spi.c#L1501)
* Would be nice to consider moving from using packed structs to
serialisation functions.
*
* lspcon_i2c_spi
[https://ticket.coreboot.org/issues/360](https://ticket.coreboot.org/issues/360)
(man page added)
* There is nothing to add to the name it seems: no model
* Is there a way to know which chip you are talking?
* We can try to improve board_enable infra for i2c, and then
we can hook i2c programmer.
* Board enable is specific to internal programmer. We could
make it more generic to support more than internal. So that it can say
“this board supports this chip”, or “no lspcon detected”.
* Lspcon should query some kind of board enable (not the
current one), and then board enable can come back and say “you are
safe to run / or not”.
* For the release we need to make sure people can’t break
their devices easily.
* TODO needs a bug1 (upgrade board enable infra), not release blocking
* Nik good suggest to have a programmer param of
“I_want_a_brick=true” to avoid accidentally picking the wrong
programmer.
* Until we have the infrastructure for i2c drivers to
allow listing drivers.
* TODO needs a bug2 for I_want_brick=true, release blocking.
Temp solution until bug1 fixed.
* Lspcon_i2c_spi_set_mpu_active in init function, is it board
specific? If I have another board, can I run the programmer, or does
it leave some gpio open?
* TODO update lspcon_i2c_spi_write_aai documentation, why it
throws an error straight away, why it is not using default aai
function. Release blocking.
* Can we find out which specific chips lspcon supports?
* TODO to add documentation at the top of the file that only
very specific chips supported. Document as much as you can on the top.
When it is working and when it is not working. Release blocking
* 
[https://github.com/Pulse-Eight/libcec/issues/280](https://github.com/Pulse-Eight/libcec/issues/280)
* Where are hardcoded SPI opcodes?
* This is a good argument for converting to opaque.
* `SWSPI_WDATA_*` defines appear to be JEDEC commands, at
least numerically. So a code comment for now until we know more.
* TODO needs a bug (converting to opaque), soft blocking release
* realtek_mst_i2c_spi
[https://ticket.coreboot.org/issues/361](https://ticket.coreboot.org/issues/361)
(man page added)
* ditto I_wanna_brick.
* https://review.coreboot.org/c/flashrom/+/65545
* TODO update the comment on `realtek_mst_i2c_spi_toggle_gpio_88_strap`
* https://review.coreboot.org/c/flashrom/+/65546
* 
[https://ticket.coreboot.org/issues/376](https://ticket.coreboot.org/issues/376)
(it says review mediatek_i2c_spi)
* ditto I_wanna_brick.
* **_TL;DR All i2c drivers 

[flashrom] Re: (no subject)

[Anastasia Klimchuk]

Hello Eduardo,

This feature is super recent, so if you are using v1.2 then it's not
there. You can, if you want, build flashrom from the latest code and
you will see progress if you add `--progress` to the command line.
But, a fair warning: building from the latest code means you get
*everything else* super recent, so do it with caution at your own
risk.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Decision making process

[Anastasia Klimchuk]

Thanks for your thoughts!

> one important point is the scope I guess, i.e. when to apply this
> process. There are certainly things that we could call a "big
> decision". The upcoming flashrom-reviewers group for Gerrit comes
> to mind, for instance. However, for many smaller decisions the
> elaborate process might bring too much overhead.

Yes I fully agree! Some things are small and can be done quickly. My
attempt to address that was saying "it doesn’t have to be for months".
Let's see how it goes? I would say, if someone thinks that a topic is
a big deal and needs to be discussed on the mailing list, they always
can (and welcome to) start a thread.

> > #2
> > When/if the discussion seems to be settled and people are in
> > agreement, the item can be added to the agenda of the meeting.
>
> What would it be specifically that "people are in agreement" about?
> to move the discussion to the next level? or about the actual decision?
> In the latter case, why would we have to continue discussing?

What I had in mind was: people are in agreement about the idea. Like:
yes this is a good idea let's do it.
The actual decision (for me) is a moment of time when an idea becomes
a goal. Which means: from that moment todos can to be described and
people can take todos. Todos are steps that need to be done to
implement the idea.
I am thinking it is easier to capture this moment of time in the meeting.

> I'd say if no consent is found on the mailing list, we should proceed in the 
> meeting?

I don't mind, so yes? I would just say "proceed with caution", I would
try to analyze what are the concerns that prevent from finding
consent. Maybe the concerns can be addressed.

> Assuming somebody already disagreed on the mailing list, we might
> just repeat what happened there if we try to make an unanimous
> decision. So should it be a majority vote? e.g. 2 out of 3 agree?
> If so, I think we should try to determine who exactly gets to vote
> in the meeting. For instance,
>
> * the people who took part in the mailing list discussion and
>   are also present in the meeting?
>
> * everybody in the meeting who read the mailing list discussion?
>
> * everybody in the meeting no matter if they read all the arguments?

This is the toughest! But I have some thoughts.
When somebody disagrees my first thing is to try to understand why,
what is the reason for a strong opposite opinion, and is there a way
to address the concerns. I will always be asking to explain the
concerns and point of view.

If nothing helps... Majority seems like a reasonable approach.

Also it happens sometimes that people say "I don't agree with this
entirely, but I don't want to block it if everyone else agrees".

From the options you described, #2 seems to make most sense:
"everybody in the meeting who read the mailing list discussion"
If it comes to this, however, we need to try and get everybody who is
actively interested to join that instance of the meeting?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Decision making process

[Anastasia Klimchuk]

Hello People,

The topic initially came up in the “Gatekeeping” thread. However it
was suggested that it should be a separate thread, which makes sense
so I am starting one.

So, straight to the point: it looks like we have a decision making
process emerging! (below).
What do people think about it?

#1
Discuss things on the mailing list first. It could be ongoing for
months - so that everyone who is interested has time to read and
respond. However, it doesn’t have to be for months.
#2
When/if the discussion seems to be settled and people are in
agreement, the item can be added to the agenda of the meeting.
#3
At the meeting the item can be discussed again, and a decision can be
made (or not made, if people disagree).
#4
After the meeting we send an email with meeting notes and “Decisions
summary” on the top of the email.
#5
Since stuff never gets done immediately, there always be some time to
react on #4

If someone has objections/concerns, it would be great if you can
propose improvements or alternative solutions. Please don’t just say
“this is all wrong!”

Many thanks for sharing your thoughts!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Request for clarification on "per-region file arguments" issue

[Anastasia Klimchuk]

Hello Daniel, Nico,

I noticed this:

> I think it would
> be best to have somebody have a thorough look through all the changes.
> Preferably somebody who didn't work on the patch because it's not easy
> to spot one's own errors.

Looking at the patch, it seems like almost everyone already worked on
it - either as developer or reviewer (which is not surprising given
that it has been 3.5 years under review and has changed many owners).
So there are not many people who can pass the condition "somebody who
didn't work on the patch" , however I realised that I do pass! :)
So I can do this, have a look and see if I spot something.

Just to be clear, unless someone objects, I am only taking item #3
from the previous email (I can see there are 3 todos in the email).
Does this sound good?

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Welcome our 2022 students!

[Anastasia Klimchuk]

I am very proud because I have great news: we have 3 students joining
the flashrom community to do projects!

Aarya will be doing a GSoC project “Optimize Erase-Function Selection”
with Thomas (Mentor), Simon (backup Mentor) and Nikolai.

Chinmay will be doing a GSoC project “Refactor arguments parser” with
Felix (Mentor), Anastasia (backup Mentor) and Evan.

Joursoir is joining as an independent contributor and will be working
on a project “Restructure shutdown functions and remove global state”
with me and Thomas. This will be a more open-ended project and largely
a continuation of the effort I was doing last year.

Anyone who is also interested in supporting the projects and our
students, yes please, you are very welcome! :)

Aarya, Chinmay, Joursoir,

it would be really great if you can join the next flashrom dev meeting
on 2nd June, so that we can say hello to each other! Info in this
thread: 
https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/5EMHJAKZNVWTYXNUARISO355KPRAOCZM/

Between today and 2nd June you will be talking to your Mentors and
discussing project plans in more detail. Please prepare: look at the
timeline (https://developers.google.com/open-source/gsoc/timeline) and
tell if you plan for example vacations so that we can adjust the
project schedule.

You will have a conversation with your Mentor(s) once a week. You will
need to post to the mailing list at least once a week, to share with
the community what’s going on your project.

Remember if you have any questions, you can always ask your Mentor(s)
and/or me or Felix. Especially if you are confused, not sure what to
do: keep calm and talk to your Mentor(s) or Admin(s).

So, what to do now? Celebrate! ;)
And then prepare for next week's conversation with your Mentors.

Good Luck!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flashrom Dev Meeting summary info

[Anastasia Klimchuk]

Hello,

I wanted to add two more FAQs here.

#5 Do I need to create an account anywhere?

No, you can join without an account.
Also you can view and comment on the meeting doc without an account.

#6 How do I add a topic to the agenda?

Add comments/suggestions on the meeting doc, and they will be accepted
shortly after.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

Thanks so much for your thoughts everyone!

I have important information for this thread. Next flashrom dev
meeting which is this Thursday (in two days), specifically:

19th May 2022, 6:00 - 7:00 am UTC+0

will be discussing flashrom release!
There are two parts in the topic: next release v1.3 and also in
general what approach we want to have for future releases.

As you see on the meeting agenda here
https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing
Flashrom release is the first topic for 19th May.
Next topic is “flashrom binaries” which is probably related to the first one.
And if there is time left, the topic after that is “flashrom
cross-platform build testing” which is also related.

Everyone who is interested to discuss flashrom release is very very
welcome to join the meeting!

Also as I mentioned before, I created issues under parent task here
https://ticket.coreboot.org/issues/353 (some of them already assigned
to people).
Alternatively you can open the list of all flashrom issues and set filters:
category == Release prep && target version == 1.3

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions regarding Easy project and GSoC

[Anastasia Klimchuk]

Hi Aarya,

Things are going well, we (Org Admins) have submitted all the
"paperwork" for the projects and are now waiting for the official
announcement!

Nico is absolutely correct, announcement will be on May 20. We are
waiting for it as much as you ;)

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Gatekeeping, ACLs and Review Rules

[Anastasia Klimchuk]

Hello,

I am also not a native English speaker, and need to always concentrate
on the language. Sometimes I can't understand the person who has just
spoken, in this case I am trying to clarify for example by asking "do
I understand you correctly, do you mean ABCXYZ?". Also I remember a
few times when I noticed you were frowning and not saying anything, I
asked you "Nico what do you think? Do you agree?" etc.

There is also a Raise Hand button, you can click when someone is
talking and you don't want to interrupt. People always pay attention
to raised hands, they are never lost.

In any case, if you have any other suggestions/strategies, please
share! We will use them. I just looked, for all the meetings we got to
the time, native English speakers are less than a half of attendees.
So any concrete suggestions on how to improve experience for all of
us, very welcome.

By the way,

> give them an inch and they'll take an ell

I don't understand this (maybe because I am non-native English). I see
this is a metaphor, but I don't understand how to map it into the
reality of flashrom project.
Who "gives"? Who are "them"? What do you mean by "inch" and what do
you mean by "ell"?

Also, in your statement
"Here's how things look like when we don't compromise"

There are two things that I don't understand.

First of all, who are "we"?

Secondly, compromise with what?
You provided a list of things you won't do, you said "I'll not" 4 times.
But what do you do?
What is your suggestion for the decision making process, can you
describe the complete process?

Just to be clear, my suggestion for decision making process:

#1 Discuss things on the mailing list first (it could be ongoing for
months, not a problem - so that everyone interested has time to read
and respond)
#2 When/if the discussion seems to be settled and people are in
agreement, the item can be added to the agenda of the meeting.
#3 At the meeting the item can be discussed again, and a decision can
be made (or not made, if people disagree).
#4 After the meeting we send an email with meeting notes and
“Decisions summary” on the top of the email.
#5 Since stuff never gets done immediately, there always be some time
to react on #4

And I am really interested in what other people think about the suggestion!


Also I am thinking: decisions from all previous meetings were fine,
you never protested before.
We had 5 meetings already, each one made at least one decision. The
number of decisions per meeting: 1, 4, 3, 1, 4.
And now you are protesting, when we decided to go ahead with your
idea? Your own good idea, which solves real issues on the project, the
issues that you regularly complain about?
I don't understand your behavior. Can you please explain why you
behave like this?


If you have concerns and the software we are currently using, you are
welcome to organise a video call with any other software that you
prefer. Create a meeting room, write instructions for people how to
join, and we will start using it. I am happy to help spread the word
and tell everyone when you set up new software, and when everything is
ready to switch from current one into a new thing.
I set up the software that I am familiar with. Me and Felix spent a
lot of time making sure all the use cases work, so that no one needs
to spend time troubleshooting during the actual meeting. So my reason
for this choice was: I know how it works, I know the features, where
are the buttons etc.


>>  Mailing list and IRC channel have been here since forever, they are
>>  good for discussions but don’t work for making decisions.

> Please, elaborate on this.

Please explain how the decision making process would work on the
mailing list. And, specifically, please define the criteria to detect
when a decision is "done".
Please give an example, a link to a flashrom mailing list thread where
the decision was made. Good thing we have archives, so even a thread
from some time ago can be linked.

I don't see a realistic way for flashrom to make decisions on the
mailing list, and I have never seen that happen.
What I see is that issues keep repeating again and again for years,
and questions are not answered.

For example, a question that was added to the agenda of the first
meeting (which was >2months ago): "how do people get commit rights on
flashrom?" No one has an answer. Gerrit groups were created in 2017,
which is 5 years ago, and yet for all the years flashrom has no rules
and no criteria on how people get commit rights! Mailing list was
functioning for all the time, so why the question haven't been
answered in 5 years?


Finally, I noticed some statements that can be misleading. Surely not
intentional, but I want things to be very very clear.

> I feared people could use the meeting to force decisions at some point.

I don't know what you meant to say, but this statement may look as if
you are suggesting that decisions are forced at the meeting.
This is not true. All the items are discussed and decisions 

[flashrom] Re: Gatekeeping, ACLs and Review Rules

[Anastasia Klimchuk]

Hello Everyone,

First of all let's summarize what has happened. Today is May 12.

Two months ago (Mar 6) Nico started this thread on the mailing list:
"Gatekeeping, ACLs and Review Rules". I recommend everyone [who is
interested] re-read the opening email in this thread. It is well
written, analyses existing issues on flashrom project, gives
historical information, suggests solutions and rationale behind the
solutions. There are several ideas, among them the idea to create a
"flashrom reviewers" group in gerrit. The group gives rights to +2
patches (but does not give submit rights).

The thread has been active for two months, and various people joined
the discussion. People either supported the idea of the "flashrom
reviewers" group, or did not comment / did not object.
After two months, the topic was raised and discussed at the dev
meeting (May 5). "flashrom reviewers" group was approved by all
attendees. We made a decision to create this group, and documented the
decision (see Meeting notes, Decision summary at 5th May 2022
https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing
). Just to be clear, Nico was present at the meeting on 5th May.

Few hours after the meeting (that was still 5th May), we sent an email
with meeting notes,
https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/VGTQITWML2DQB7U52OVC7NDDHPOHJYJ5/
Email contains meeting notes in full, and if someone is busy and has
no time to read notes in full, there is "Decision Summary" at the top.

Next day, 6th May I posted to this thread, once again announcing that
we made the decision to create "flashrom reviewers" group and asked
Martin to help. He really helped and created a patch
https://review.coreboot.org/c/flashrom/+/64101 . The patch is under
review, it has some comments.

So I want to confirm that all steps for discussion and decision were
done properly and publicly.

Secondly, let's summarize the issues solved by the "flashrom
reviewers" group and next goals.

In the absence of "flashrom reviewers", everyone in "coreboot
reviewers" has rights to +2 flashrom patches. "coreboot reviewers" is
a large group, not all people know flashrom code well, not all people
work on flashrom. Which leads to repeated complaints like "Why was
this patch merged? It wasn't properly reviewed!" Mostly Nico
complained about that, so not surprisingly he described the issue and
suggested the solution (see the opening email in the thread).

Another point, having our own group makes it much more clear for patch
owners on what the expectations are. A reviewer who has +2 right has
enough experience on flashrom and can approve the patch. If a reviewer
only says +1 this means someone else needs to approve, or patch needs
more work.

What is the initial list of people in the group? Thankfully, Nico has
a good and reasonable suggestion in the first email, too:

> Changing this would imply that we need our own group of reviewers.
> With this, a +2 would become both rarer and stronger.
> If this idea meets some consent, I
> would propose to copy the "flashrom developers" group for a start.
> And when we identify somebody over time who shows in-depth knowledge
> about at least a part of flashrom and good self-judgement if they
> are experienced enough for a +2, we could add them. Right now, some
> candidates come to mind already, Peter, Nikolai, and Thomas.

The very important next goal to discuss: the rules and criteria on how
to add new people into the "flashrom reviewers" group. We could not
enforce any rules on coreboot reviewers, but now once we have our own
group, we can have our own rules.
Similarly, "flashrom developers" group has no rules defined. We should
discuss this too.

Great thing is that now flashrom has a place where core devs and
active members of the community can make decisions: we have a meeting!
 Mailing list and IRC channel have been here since forever, they are
good for discussions but don’t work for making decisions.
A project needs a place where decisions can be made.

And one more thing, I noticed there are some incorrect statements on
this thread. I am sure this was not intentional, very likely just
emotional, but still I want things to be very very clear.

> That change[1] is mostly unrelated to what was discussed

This is not true. The patch
https://review.coreboot.org/c/flashrom/+/64101 is modifying gerrit
config and adding "flashrom reviewers" group, which is exactly what
was discussed.
However, the patch is doing two things in one, so I added a comment
and asked if it is technically possible to split.

> IIRC, we decided (first meeting?) to keep using the mailing list for decisions

This is not true. Decisions summary for the first meeting has one item:
"Will make this meeting bi-weekly until we've worked our way through
the issues listed here."
I checked the decision summary for all the meetings we had to that
time, none of them said we "keep using the mailing list for

[flashrom] Re: Gatekeeping, ACLs and Review Rules

[Anastasia Klimchuk]

There are several questions raised in this thread, but good news is
that at the meeting yesterday one of the questions was decided on!

We decided to have a Reviewers group for flashrom.

Martin, can we ask you to help with creating a group? If you could
help that would be great!
Initial content of the group (as it is suggested in the starter email)
is a copy of “flashrom developers”, and then we can add people on the
top.
Thank you!

Given the existing "flashrom developers" , maybe a new group can be
called "flashrom reviewers"?

On Sat, Mar 26, 2022 at 9:11 PM Anastasia Klimchuk  wrote:
>
> Hello!
>
> > and I vote 100% against it. FWIW, this feature wakes our worst in-
> > stincts. No matter how convinced we are that review is also for our
> > own good, getting a commit merged always feels rewarding. And many
> > people act like it's a necessity to set the resolved tick to gain
> > that reward. I've seen people doing so with every single comment they
> > wrote since day 1 when this feature was activated for coreboot. Let's
> > not repeat every mistake made there.
> >
> > Also, today Gerrit warns about unresolved comment threads when one
> > tries to submit. Enforcing it brings a marginal convenience but makes
> > the review process less friendly in my experience.
> >
> > Sometimes comment threads are opened after review. So the `merged`
> > status never implies all-comments-resolved. And that's not bad, IMHO.
> > Sometimes things come up after review and Gerrit makes it easy to
> > continue to discuss changes even after they are merged.
>
> I have mixed feelings about this. On one hand, I understand what you
> are saying about worst instincts, especially since you are saying you
> observed examples how the feature can be workarounded. On the other
> hand, it seems logical to me to have two types of comments: major ones
> that need to be resolved before merging the patch, and everything else
> (non-blocking).
> Also, I am totally fine to leave as is: my own workflow won’t change.
> I learned over the years that people have a variety of opinions about
> yellow and grey comments, my workflow is trying to cover all of that
> anyway :)
>
> > There also seems to be a misunderstanding about patches. Some people
> > seem to believe that every patch should get merged eventually.
>
> I think, you gave a perfect explanation to this just above: “getting a
> commit merged always feels rewarding”
>
> > IMO, problematic patches should not be escalated but avoided in the
> > first place. In our wiki it says in multiple places that one should
> > discuss things on the mailing list early so nobody gets frustrated
> > later. Such problematic reviews is exactly why it's stated there.
> > Open-source development is nothing new. Many problems have been fixed
> > in the past already. Please always encourage everybody to try the
> > established ways before experimenting with new ones.
>
> That’s all correct, for sure! But sometimes, established ways do not
> work (for whatever reasons). And boom, we have a problematic patch. It
> should not exist, but here it is. You called this “escalation” but
> what if it is only reviewers discussing, it is not an escalation, it’s
> the same people who are on the patch, just talking instead of typing?
> And yes, if everything goes normally , it’s not needed.
>
> Re: encouragement, I always do what I can!
>
> > If we don't revert first, it
> > will create pressure to fix things right now (which may break things
> > again).
>
> Agree with that! I agreed with that from the very beginning :)
>
> > something like "Do you want to write
> > that for upstream, there's the development guidelines: https://...;.
>
> Believe it or not, guidelines are something that we recently discussed
> (guidelines for people who send patches upstream). But I need to work
> on this a bit, I will tell later!
>
> However one topic I am not sure how to guide is: gerrit comments. The
> only thing I understand by now, there are various opinions on gerrit
> comments.
>
> Also, returning back to initial questions, an idea of having a
> Reviewers group for flashrom.
> Does this look good for everyone?
> This comes together with a question: what are criteria to add someone
> to Reviewers and Committers?
>
> This probably needs some brainstorming, so I am going to start, I give
> it 5 mins, everything that comes to mind:
>
> Number of patches owned [for last X months/years]
> Number of patches reviewed [for last X months/years]
> Number of patches merged [for last X months/years]
> Last time the patch was reviewed
> Last time patch was send to review
> Last tim

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

I have great news: I created items for the release in our bugtracker!

Here is a parent issue “Release v1.3” https://ticket.coreboot.org/issues/353
and it has 23 subtasks. The subtasks are the items from the original
starter email. Thank you so much Nico for going through the long history
and making the list, that’s a lot of work and time!

The very good thing is that now the big task is trackable, parallelizable
and open to anyone who can join the effort.

I looked into commits and gerrit reviews that correspond to those, I tried
to get some context. Surely all of the descriptions can be improved, or
more info can be added to issues. Especially if you are taking an issue and
start working on it.

Also, of course, more tasks can be added, if something is missing. Please
set the parent issue #353, category “Release prep” and target release 1.3
if you add a new task.

I assigned the parent issue to myself. Please tell me if anyone has
objections. I did it because at the last dev meeting the community decided
that I will be “release manager”. It was completely unexpected for me, but
it is true to say that I very much want the release to happen.
I really appreciate any help and advice from people!

As a separate note, the question of meson and make has been discussed in
this thread. And we now have a One Build System working group with the goal
to converge two flashrom build systems into one (meson). Here is the doc
with more info
.
Everyone who is interested in contributing to the effort can join! This
effort goes in parallel with release prep.

I haven’t done any releases before, so tell me if I am wrong. But what I am
thinking when looking at the list of issues: maybe we can have some time
for “just fixing issues on master” and after that do a release branch? Does
it make sense?
“Some time” won’t take forever (AU winter maybe?). I have issue #353
assigned to me, so now it has to happen :)


On Thu, Mar 24, 2022 at 2:34 AM Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2...@gmx.net> wrote:

> Hi Richard,
>
> Am 23.03.22 um 10:20 schrieb Richard Hughes:
> > On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
> >  wrote:
> >> AFAIR there were three arguments for meson:
> >> - Meson build integrates nicely with other packages built by meson
> > This means we can build libflashrom as a subproject, which means we
> > can build the flashrom plugin even when the distro doesn't ship [a new
> > enough] flashrom package:
> > https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
> >
> > That's just something you can't do with the Makefile, and removing the
> > subproject would force us to remove flashrom support from almost all
> > the CI systems we test fwupd with.
>
> It took me some time to understand the text of this last sentence, but
> I'm unsure about the implied subtext.
> The first paragraph implies that a fwupd build can rebuild flashrom as
> well. Interesting. In that case a Meson wrapper for Makefile might
> satisfy your requirements in principle, but not in spirit.
>
> For the subtext of the last sentence I'm not sure if the intended
> understanding was "use Meson or we'll drop flashrom" or "give us a way
> to keep our CI running with flashrom" or something entirely different.
> Sorry, English is not my native language. I'm trying understand if this
> is a technical (something doesn't work) or social (something is
> frustrating) problem or both. Analyzing your statement above with the
> linguistic tools of Schulz von Thun and Watzlawick gave me the
> impression that I'm missing something here.
>
>
> >> - Native support for most non-Linux platforms
> > I keep hearing this, but haven't got any actual data -- is there any
> > reason why the meson build system wouldn't "just work" with
> > *BSD/Win32/macOS?
>
> Someone would have to test it and document it. This also includes
> crossbuilds for MacOS and DOS on Linux which are both supported with
> Makefile.
> Documentation for the various Makefile based builds is available at
> https://github.com/flashrom/flashrom/blob/master/README . Copy/paste
> from a README is something that "just works". This is currently missing
> for our Meson build.
>
>
> >> I think Meson was a good idea, but it failed to get traction beyond "we
> >> need it for dynamic libflashrom".
> > I don't know how you've managed to get to "failed to get traction"
> > given that it's being built with meson in 4 of the biggest projects
> > (in terms of distribution, and number of deployed packages) using
> > flashrom.
>
> The switch to Meson in Debian has resulted in some regressions which
> caused people to join #flashrom IRC. Not all of the regressions were
> fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody
> bothered to check the Meson build result and compare it to the Makefile
> reference" would be a more accurate description.
>
> This caused a mismatch between 

[flashrom] Code Reviews guidelines discussion

[Anastasia Klimchuk]

Hello People,

Few weeks ago at the flashrom meeting we had a discussion about code
reviews and the situations that sometimes happen. We decided that it
would be good to have some guidelines… and then we decided that I will
start writing something. I have been thinking about it since then. I
even started writing something, but I wasn’t happy at all: it felt
like composing a wall of text that no one would be reading.

I decided to think about: what problems are we solving? And then it
got much better. I gathered the list of problems that I think are
present and repeatedly happen during code reviews. All of the below is
RFC and of course, if there is a problem that is missing, please tell.

I would really appreciate everyone’s opinions on this!

What I suggest is: after agreeing on the list of problems, compose and
agree the answers to them (yes easier to say then to do :)), and then
it can be like “Code Reviews FAQ” or something like that? Especially
if we can encourage people to read the other point of view first.

—--
## Contributor point of view ##
—--

#1 Is this comment a conversation or an action item?

#2 Is this comment blocking patch from merging or non-blocking?

#3 Are we waiting for anyone [else] to have a look at this patch?

#4 Is my patch ready to be merged? / Why is my patch not being merged?

#5 Who are the best reviewers for this patch?

#6 This patch is a real emergency, what is the process for that?

—-
## Reviewer / Maintainer point of view ##
—-

#1 My important comment(s) got ignored and the patch was merged regardless.

#2 I have so many code reviews, and everyone wants it fast and
complains reviews are too slow.

#3 A patch that was merged broke something, but people don't want to revert.

#4 I asked the patch owner to fix something, but they are arguing with
me instead, and wasting everyone's time.

#5 What this patch is doing, and why is it needed?

#6 I want to review the patch, but I am busy for the next X weeks.
-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Flashrom Dev Meeting summary info

[Anastasia Klimchuk]

Hello People,

I wanted to summarise the information on the time of Dev meeting. At some
point there was an idea to alternate times, but then we discovered that we
got really lucky and there is one time which everyone agrees on. That was
an open question at the last meeting, to confirm the time with those US
folks who were not present. Since no one was replying to the mailing list,
I reached out to folks and confirmed the time is fine.

—-
SUMMARY
—-

#1 Between November and March (inclusive) time of meeting:

Wednesday 21:00-22:00 UTC+0

also known as
Wednesday 13.00-14.00 Pacific Standard Time UTC-8
Wednesday 22.00-23.00 Central European Time UTC+1
Thursday 8.00-9.00am Australian Eastern Daylight Time UTC+11

#2 Between April and September (inclusive) time of meeting:

Thursday 6.00-7.00am UTC+0

also known as
Wednesday 11pm-midnight Pacific Daylight Time UTC-7
Thursday 8.00-9.00am Central European Summer Time UTC+2
Thursday 16.00-17.00 Australian Eastern Standard Time UTC+10

#3 Note that in the last week of March and 4 weeks of October there will be
no meetings, because daylight saving time changes are happening on
different dates in different locations, and setting up meeting time becomes
too complicated.

Once the regularity is stable, I will add info about Dev meeting on the
Contacts page.
Meanwhile:

—
FAQ
—

#1 When is the next meeting?

Look into the meeting notes document
.
The top entry, on the first page, with the date in the future, and empty
list of attendees - is the next meeting.

#2 How to join the meeting?

Look into the meeting notes document
.
On the top it says “to join, click the link”, click the link.

#3 Where is that document?

Meeting notes document is linked to the Home page of flashrom.org,
Developers menu at the bottom of the page.

#4 Do I need an invitation to join the meeting?

No, just join.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions regarding Easy project and GSoC

[Anastasia Klimchuk]

Aarya,

This is amazing news, I am super happy to get your project proposal!
It is nice to have you with us :)

We have long public holidays here (in AU), but I had a quick look and
the proposal looks fine.

Once the holidays are over, we, together with mentor(s), will go
through the proposal carefully, define next steps, and of course will
inform you on how things are going. For now, you did everything right,
and submitted the project proposal at the right time. Thanks! :)

On Sat, Apr 16, 2022 at 5:22 AM Aarya Chaumal  wrote:
>
> Anastasia and Felix,
>
> I submitted my proposal for "optimize erase function selection" yesterday 
> after which I received an acknowledgment mail saying "Your project proposal 
> for GSoC 2022 to Flashrom has been submitted. Mentors will review your 
> proposal and possibly contact you with questions." Just wanted to ask if you 
> have any questions or suggestions regarding it.
> Also, I have decided not to write a proposal for the other project I was 
> interested in i.e. "Fix endianness issues" as writing a proposal already 
> takes a lot of time and effort that I can't give more due to my college 
> exams. Although, I would love to do it after GSOC if the project remains 
> available then.
>
> Aarya.
>
>
> On Mon, Apr 11, 2022 at 5:45 PM Nico Huber  wrote:
>>
>> Hi Aarya,
>>
>> On 11.04.22 13:46, Aarya Chaumal wrote:
>> > In the "Optimizing Erase Function Selection" project what is considered a
>> > minimum level of success. I think it should be that the resulting average
>> > erase time should be similar to the theoretical value based on the
>> > implemented algorithm and less than the current erase time.
>>
>> theoretical values are hard to get right. Beside the documented
>> delays of a flash chip, we have delays in the programmer and in
>> case of external programmers round-trip delays on the bus where
>> they are attached (e.g. USB, UART).
>>
>> As the current code is implicitly optimized for smaller changes,
>> I would define basic success as reducing the programming time
>> for a full flash-chip write (could be tested by writing random
>> data) without increasing the time for a small change (e.g.
>> write random data with a layout region of 4KiB).
>>
>> > Are there any
>> > other objectives that need to be achieved for the project?
>>
>> IIRC, the description mentioned a prerequisite: We need to know
>> in advance if the programmer will be able to execute a specific
>> erase command. This is very important so we can get rid of the
>> current fallback strategy that simply tries the next command
>> if one fails.
>>
>> The fallback strategy is somewhat controversial anyway: If the
>> programmer rejects a command, it's reasonable to try another.
>> However if an erase fails due to hardware trouble (transfer
>> failure or even the flash chip failing), trying again with a
>> bigger erase block size can make things worse.
>>
>> >
>> > Also what stretch objectives could be there for the project?
>>
>> Maybe optimization for more write patterns (re-writing a full
>> flash doesn't happen very often). However, we'll have to see
>> if that is possible/necessary. Maybe one could take the indi-
>> vidual erase times of a flash chip into account. For instance
>> if a 4KiB erase takes x ms and a 64KiB erase takes 10*x, then
>> it might speed things up to use the bigger erase block even if
>> it wouldn't have to be fully erased.
>>
>> Nico



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: [GSoC 2022] Restructure Shutdown Function

[Anastasia Klimchuk]

> Due to current circumstances, Google isn't accepting participants from
> the country where I'm currently located. So, I can't take part in GSOC 2022.
> But I am still interested in participating in flashrom and this project.
> What should I do now? Send small patches and study the code until 20th
> May? And if no one will choose this project, then I can take part in
> it, right?

Yes, it’s a good plan! You can be an independent contributor. This
will give you more flexibility, since you won’t depend on a strict
timeline.

Sending small patch(es) in the beginning is very useful, you will
create a gerrit account, learn how to push a patch, learn how to go
through code review - all of these are skills that you need. You can
do a project from Easy Projects. For the first one “Fix scan-build
issues” some issues have patches under review at the moment, but there
are still issues left.

You can also send a small patch on something more close to the topic
of the project. You can suggest one, or I can think of something.

> So, about project details. I've understood everything, except one thing.
> Eventually, are we not going to remove shutdown() func from the struct
> spi_master and move it in struct programmer_entry? Will we keep shutdown()
> in the struct spi_master and not in the struct programmer_entry for SPI
> programmers?

Yes, shutdown lives in spi_master and it will stay there (and also
par_master and opaque_master). The reason is that the shutdown
function needs data, and data lives in spi_master struct. Also data is
something that is used instead of global state (so every programmer is
using its own data, or will be).
I was trying to find relevant discussions from last year, and I think
comments threads on these two patches are:
https://review.coreboot.org/c/flashrom/+/55932
https://review.coreboot.org/c/flashrom/+/56103

This is also relevant to what Thomas was saying:

> What do you think of exposing the bus master(s) and the shutdown
> function through the programmer_entry struct instead of register them
> in the programmer code.

On Sun, Apr 10, 2022 at 9:43 PM Joursoir  wrote:
>
> Hello Thomas and Anastasia,
>
> Due to current circumstances, Google isn't accepting participants from
> the country where I'm currently located. So, I can't take part in GSOC 2022.
> But I am still interested in participating in flashrom and this project.
> What should I do now? Send small patches and study the code until 20th
> May? And if no one will choose this project, then I can take part in
> it, right?
>
> So, about project details. I've understood everything, except one thing.
> Eventually, are we not going to remove shutdown() func from the struct
> spi_master and move it in struct programmer_entry? Will we keep shutdown()
> in the struct spi_master and not in the struct programmer_entry for SPI
> programmers?
>
> --
> Joursoir
>
> On Sat, 9 Apr 2022 20:29:57 +1000
> Anastasia Klimchuk  wrote:
>
> > Hi Joursoir,
> >
> > Sorry for some delay, I wanted to respond more to the topic and
> > finally found time :)
> >
> > > As I understood, they use the following approaches:
> > >
> > > 1. Register a callback by its own
> > >
> > > if (register_shutdown(serprog_shutdown, NULL))
> > > goto init_err_cleanup_exit;
> > >
> > > 2. Fill `struct spi_master` shutdown-callback
> > >
> > > static struct spi_master spi_master_dediprog = {
> > > ...
> > > .shutdown = dediprog_shutdown,
> > > };
> > >
> > > Is there any significant difference in this approaches? Or does it just
> > > depend on code flow?
> >
> > As a long-term goal, we are replacing all #1 with #2. Lots of #1 cases
> > were migrated to #2 last year, however some of the occurrences of #2
> > still left. They need to be migrated too. So if you see a programmer
> > which is calling `register_shutdown` in its code, then it needs to be
> > migrated, and I would count this as a task in scope of the
> > “restructure shutdown functions” gsoc project.
> >
> > Some background why #2 is preferred and we are migrating into it:
> >
> > Every master needs to register itself at the end of init function. For
> > example for spi masters it is `register_spi_master`. You can see this
> > function is called at the end of initialisation.
> > As a part of registration, a master needs to register its shutdown function.
> >
> > Now, #1 means registering shutdown function and registering the master
> > itself are two different function calls, and every master needs to
> > take care of two calls. Which means, you can call one registration and
> > forget the other, you can call them i

[flashrom] Re: [GSoC 2022] Restructure Shutdown Function

[Anastasia Klimchuk]

Hi Joursoir,

Sorry for some delay, I wanted to respond more to the topic and
finally found time :)

> As I understood, they use the following approaches:
>
> 1. Register a callback by its own
>
> if (register_shutdown(serprog_shutdown, NULL))
> goto init_err_cleanup_exit;
>
> 2. Fill `struct spi_master` shutdown-callback
>
> static struct spi_master spi_master_dediprog = {
> ...
> .shutdown = dediprog_shutdown,
> };
>
> Is there any significant difference in this approaches? Or does it just
> depend on code flow?

As a long-term goal, we are replacing all #1 with #2. Lots of #1 cases
were migrated to #2 last year, however some of the occurrences of #2
still left. They need to be migrated too. So if you see a programmer
which is calling `register_shutdown` in its code, then it needs to be
migrated, and I would count this as a task in scope of the
“restructure shutdown functions” gsoc project.

Some background why #2 is preferred and we are migrating into it:

Every master needs to register itself at the end of init function. For
example for spi masters it is `register_spi_master`. You can see this
function is called at the end of initialisation.
As a part of registration, a master needs to register its shutdown function.

Now, #1 means registering shutdown function and registering the master
itself are two different function calls, and every master needs to
take care of two calls. Which means, you can call one registration and
forget the other, you can call them in different order, you can have
an error and fail in between calls, and leak resources… In other
words, #1 means there are many ways to use the registration API (too
many), and most of them are wrong ways :( Very common problem was
leaking memory and other resources on error paths.

#2 approach means there is only one call to do: register master.
Registering shutdown function is done inside it. #2 does not solve all
possible problems, but it does solve some of them. It is less
error-prone, and that’s important.

Summary: I would count converting all remaining cases of #1 into #2 as
a part of the project.

> I went ahead and started looking into shutdown functions. Almost of
> them use global variables

They shouldn’t use global variables. SImilarly to my previous point,
lots of masters were migrated last year not to use global variables.
Shutdown function has an argument `data` and it should use it.

In the project ideas list, there is a separate idea “remove global
state”. But as Thomas mentioned, it is very related to “restructure
shutdown functions”, and yes it is. In reality, that would be a
project that has both goals touched. But that’s fine, that’s even more
fun :)

More information on the topic.

Given that the main side-effect of shutdown functions issues is memory
leak and other resources leak, there is another idea. I have to admit,
idea is currently exists in my head but still:

At the moment every master has to do its own memory management,
allocate and free memory for its own state. Memory management can be
also moved under API, so that master cannot “forget” to free
resources.

Another way to enforce memory management is to write lifecycle unit
tests for all programmers. Unit tests are all configured with memory
checks, so if you run a scenario “initialise programmer -> shutdown
programmer” and memory leaks after that, then the test will fail.
There is a gsoc project idea for unit tests :) As a fact from flashrom
history, the very first lifecycle unit test I wrote found a memory
leak!

And the last thing, there is an idea, an open question at the moment,
whether it should be required for master to have a shutdown function
(it is not required at the moment). If we decide positive on that,
there is work to do to make it possible to have shutdown function
required.

I think that’s all that I wanted to say. But I am wondering what
Thomas is thinking about it?
In any case there is plenty of useful stuff that can be done, and it
is not a problem to wrap it as a project.
Let us know what you think! ;)

On Wed, Apr 6, 2022 at 4:24 AM Thomas Heijligen  wrote:
>
> Hi Joursoir,
>
> On Mon, 2022-04-04 at 14:57 +0300, Joursoir wrote:
> > Hello Thomas,
> >
> > No problem, thanks for your reply. I have one more question. I have
> > noticed
> > that some programmers already have their own context (for example
> > pony_spi.c,
> > rayer_spi.c. serprog.c, dediprog.c and others). I note that they are
> > all
> > SPI. As I understood, they use the following approaches:
> >
> > 1. Register a callback by its own
> >
> > if (register_shutdown(serprog_shutdown, NULL))
> > goto init_err_cleanup_exit;
> >
> > 2. Fill `struct spi_master` shutdown-callback
> >
> > static struct spi_master spi_master_dediprog = {
> > ...
> > .shutdown = dediprog_shutdown,
> > };
> >
> > Is there any significant difference in this approaches? Or does it
> > just
> > depend on code flow?
> >
> The goal is the same. To reduce the global state and the number 

[flashrom] Re: EU/AU flashrom dev meeting appointment time change

[Anastasia Klimchuk]

Hello,

As we discovered at the last meeting, the slot of time that was meant
to be for EU/AU, can potentially work for US folks too.
This would be ideal (to have one time for everyone), but let’s confirm
whether it is true.

This is a question for US folks who are interested to attend: would
the following time work for you between Apr and Sept?

Thursday 6.00-7.00 am UTC+0
which is
Wednesday 11pm-Midnight Pacific Time UTC-7
Thursday Midnight-1am Mountain Time UTC-6

Thank you!

On Wed, Apr 6, 2022 at 9:30 AM Anastasia Klimchuk  wrote:
>
> ATTENTION ATTENTION
>
> We are locking the time for dev meeting. This time is optimised for
> EU/AU and will be used from April to September (inclusive).
> —---
> Thursday 6.00-7.00 am UTC+0
> —---
>
> This means 8.00-9.00 am for Germany, 16.00-17.00 for Sydney.
> The next meeting is this Thursday 7th April 2022 6.00-7.00 am UTC+0.
>
> A note for US folks. Depending on where you are in the US, meeting
> starts between 11pm and 2am local time. That’s because this slot is
> optimised for EU/AU and there will be another, alternating time, which
> is optimised for EU/US. However, if you are in the US and you are okay
> with this time (start between 11pm and 2am) you are welcome to join of
> course!
>
> Thank you everyone.
>
> On Mon, Apr 4, 2022 at 8:25 PM Anastasia Klimchuk  wrote:
> >
> > Hello People,
> >
> > I wanted to say that the meeting will be happening this week! If you
> > have any preferences for days/times, please vote on the poll, it is
> > not too late.
> >
> > At the moment there are 3 slots on Thursday that look good, and if
> > there are no other votes we will pick one of them (that would be 7th
> > April):
> >
> > Thursday 6:00-7:00 UTC+0
> > Thursday 7:00-8:00 UTC+0
> > Thursday 9:15-10:15 UTC+0
> >
> > Thank you!
> >
> > On Thu, Mar 31, 2022 at 9:20 AM Felix Singer  wrote:
> > >
> > > Hi all,
> > >
> > > as discussed in the last dev meeting, we can not have one appointment
> > > for EU, AU and US people during the time from 1. April until 30.
> > > September because of the time change. For this time, we have decided to
> > > split the meeting up into one meeting for EU/AU and another one for
> > > EU/US and we will alternate between them, so that all groups have a
> > > chance to participate.
> > >
> > > The next meeting will be on 6. April, which will target EU/AU.
> > >
> > > We created a poll [1] for voting. For EU/AU, we are proposing the
> > > following dates (UTC+0):
> > >
> > >   * Monday, Wednesday, Thursday 7:00-8:00
> > >   * Monday, Wednesday, Thursday 9:15-10:15
> > >
> > >
> > > // Felix
> > >
> > > [1] https://terminplaner4.dfn.de/dBtjEZxKqmcm721C
> > > ___
> > > flashrom mailing list -- flashrom@flashrom.org
> > > To unsubscribe send an email to flashrom-le...@flashrom.org
> >
> >
> >
> > --
> > Anastasia.
>
>
>
> --
> Anastasia.



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Join GSoC

[Anastasia Klimchuk]

Hi Sayed,

You should start by reading our guidelines here: https://www.flashrom.org/GSoC

On Thu, Apr 7, 2022 at 3:22 AM Sayed Mohsen  wrote:
>
> I also need to know if am I late for joining or its good time for me to join
> Thank you
>
> On Wed, Apr 6, 2022 at 5:59 PM Sayed  wrote:
>>
>> Hello
>> I need to contribute a project of yours in GSoC
>> Please tell me what I’m supposed to do to be able to join this program
>> Thanks alot
>>
>>
>>
>> Sent from Mail for Windows
>>
>>
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: GSOC 2022

[Anastasia Klimchuk]

Hi Wynn,

Nice to have you interested in Flashrom! Yes of course we are
interested in applicants for 2022, it is the good time now: the
application window has just opened a few days ago.

> As many of the projects require programmers, flash chips, and hardware, I was 
> wondering to what extent I would need to have these.

It depends on a project. The first project idea that you mentioned
"Emulate hardware and filesystem in platform-independent way for unit
tests" does not require additional hardware. The goal of the project
is to emulate hardware, so all the code written under it, will be
running without any hardware. You will need, however, to understand
how hardware is supposed to work, in order to emulate it.

> Additionally, I noticed that some projects want low-level programming, which 
> I would be interested in. However, as I have only a small amount of 
> experience with MIPS, would it not be worthwhile to apply to this position?

This also depends on the project idea. Some ideas are more of
"application development", which is focused on flashrom as an
application. For such ideas, a small amount of experience with MIPS is
fine.

The last thing: please check our guidelines here:
https://www.flashrom.org/GSoC . Good luck!

On Fri, Apr 8, 2022 at 3:43 AM Wynn K  wrote:
>
> Hello, I recently found this project and was wondering if this project was 
> still interested in applicants for the 2022 summer. I was looking into the 
> project ideas and am looking into "Emulate hardware and filesystem in 
> platform-independent way for unit tests" and "Optimize Erase-Function 
> Selection". As many of the projects require programmers, flash chips, and 
> hardware, I was wondering to what extent I would need to have these. I saw 
> the following lists which demonstrate the supported hardware, but I would 
> appreciate it if I could have a more descriptive explanation of what I would 
> need. https://www.flashrom.org/Supported_programmers
> https://www.flashrom.org/Supported_hardware
>
> Additionally, I noticed that some projects want low-level programming, which 
> I would be interested in. However, as I have only a small amount of 
> experience with MIPS, would it not be worthwhile to apply to this position?
>
> Thank you for your time
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: EU/AU flashrom dev meeting appointment time change

[Anastasia Klimchuk]

ATTENTION ATTENTION

We are locking the time for dev meeting. This time is optimised for
EU/AU and will be used from April to September (inclusive).
—---
Thursday 6.00-7.00 am UTC+0
—---

This means 8.00-9.00 am for Germany, 16.00-17.00 for Sydney.
The next meeting is this Thursday 7th April 2022 6.00-7.00 am UTC+0.

A note for US folks. Depending on where you are in the US, meeting
starts between 11pm and 2am local time. That’s because this slot is
optimised for EU/AU and there will be another, alternating time, which
is optimised for EU/US. However, if you are in the US and you are okay
with this time (start between 11pm and 2am) you are welcome to join of
course!

Thank you everyone.

On Mon, Apr 4, 2022 at 8:25 PM Anastasia Klimchuk  wrote:
>
> Hello People,
>
> I wanted to say that the meeting will be happening this week! If you
> have any preferences for days/times, please vote on the poll, it is
> not too late.
>
> At the moment there are 3 slots on Thursday that look good, and if
> there are no other votes we will pick one of them (that would be 7th
> April):
>
> Thursday 6:00-7:00 UTC+0
> Thursday 7:00-8:00 UTC+0
> Thursday 9:15-10:15 UTC+0
>
> Thank you!
>
> On Thu, Mar 31, 2022 at 9:20 AM Felix Singer  wrote:
> >
> > Hi all,
> >
> > as discussed in the last dev meeting, we can not have one appointment
> > for EU, AU and US people during the time from 1. April until 30.
> > September because of the time change. For this time, we have decided to
> > split the meeting up into one meeting for EU/AU and another one for
> > EU/US and we will alternate between them, so that all groups have a
> > chance to participate.
> >
> > The next meeting will be on 6. April, which will target EU/AU.
> >
> > We created a poll [1] for voting. For EU/AU, we are proposing the
> > following dates (UTC+0):
> >
> >   * Monday, Wednesday, Thursday 7:00-8:00
> >   * Monday, Wednesday, Thursday 9:15-10:15
> >
> >
> > // Felix
> >
> > [1] https://terminplaner4.dfn.de/dBtjEZxKqmcm721C
> > ___
> > flashrom mailing list -- flashrom@flashrom.org
> > To unsubscribe send an email to flashrom-le...@flashrom.org
>
>
>
> --
> Anastasia.



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: EU/AU flashrom dev meeting appointment time change

[Anastasia Klimchuk]

Hello People,

I wanted to say that the meeting will be happening this week! If you
have any preferences for days/times, please vote on the poll, it is
not too late.

At the moment there are 3 slots on Thursday that look good, and if
there are no other votes we will pick one of them (that would be 7th
April):

Thursday 6:00-7:00 UTC+0
Thursday 7:00-8:00 UTC+0
Thursday 9:15-10:15 UTC+0

Thank you!

On Thu, Mar 31, 2022 at 9:20 AM Felix Singer  wrote:
>
> Hi all,
>
> as discussed in the last dev meeting, we can not have one appointment
> for EU, AU and US people during the time from 1. April until 30.
> September because of the time change. For this time, we have decided to
> split the meeting up into one meeting for EU/AU and another one for
> EU/US and we will alternate between them, so that all groups have a
> chance to participate.
>
> The next meeting will be on 6. April, which will target EU/AU.
>
> We created a poll [1] for voting. For EU/AU, we are proposing the
> following dates (UTC+0):
>
>   * Monday, Wednesday, Thursday 7:00-8:00
>   * Monday, Wednesday, Thursday 9:15-10:15
>
>
> // Felix
>
> [1] https://terminplaner4.dfn.de/dBtjEZxKqmcm721C
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions regarding Easy projects

[Anastasia Klimchuk]

Hi Prakhar,

It is nice to know that you are interested in Flashrom. However, by
the nature of our projects students need to have a deep level of
knowledge and experience in C language. I would encourage you to learn
more C, and maybe find out the answers to your questions by yourself.

Good Luck!

On Sun, Apr 3, 2022 at 8:32 PM Prakhar Agrawal
 wrote:
>
> Hello,
>
> Hope you are doing well, I am Prakhar Agrawal, currently pursuing Electronics 
> and Communications Engineering from Amrita Vishwa Vidhyapeetham Amritapuri. 
> (2019-2022).
>
> For the past  1 year, I have been working with startups to design and develop 
> low latency embedded devices and have also been actively involved in running 
> and managing the bi0s students club(India's best CTF team)
>
> While going through different organizations for GSOC 2022, I found Flashrom, 
> and it caught my interest.
>
> I was trying to get familiar with the flashrom code-base through easy 
> projects listed here
>
> I had a few queries in 'Fix issues found by scan-build':-
>
> In serprog.c,
> function
> static int sp_stream_buffer_op( ),
>  if (!sp) {
> msg_perr("Error: cannot malloc command buffer\n");
> return 1;
> }
> sp is a pointer, in which a block of memory is being allocated, but in this 
> function,  if (!sp) i.e pointer is not null, i.e the memory has been 
> allocated, then why should there be an error message?
> While fixing the error generated from the error report, null was being passed 
> to memcpy, here
> if (sp_stream_buffer_op(S_CMD_O_EXEC, 0, NULL) != 0)
> to try and fix this issue, I updated the function definition
> static int sp_stream_buffer_op(uint8_t cmd, uint32_t parmlen, uint8_t *parms){
> uint8_t *sp;
> if (sp_automatic_cmdcheck(cmd))
> return 1;
> sp = malloc(1 + parmlen);
> if (!sp) {
> msg_perr("Error: cannot malloc command buffer\n");
> return 1;
> }
> sp[0] = cmd;
> /*
> * Fixed: Added an If block to check the parameter length,
> * if parameter length is 0 i.e- param is NULL return 1,
> * else do memcpy
> */
> if(parmlen==0){
> //memcpy(&(sp[1]),0, parmlen);
> msg_perr("Error: Cannot pass Empty parameter\n");
> return 1;
> }
> else{
> memcpy(&(sp[1]),parms, parmlen);
> }
> The above changes fixed the error of null value being passed, but now I am 
> getting a memory leak error.
>
> Can someone guide me in the right direction on how to fix it?
>
> Hoping for a quick and positive response.
>
> Warm Regards
> Prakhar Agrawal
> Amritapuri
> LinkedIn
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Inquiry about a required task for GSOC.

[Anastasia Klimchuk]

Hello Israa,

Thank you for contacting us! Unfortunately, "Modernize the flashrom
website" project is not available for GSoC 2022 anymore. I really
apologize for the inconvenience, and confusion.

The reason is, we had some discussion recently about the project and
realised that the project is not well-defined, not ready for this
year's GSoC. There is a lot of research-style work that needs to be
done to define the task, and research-style work is not a good fit for
GSoC.

It is all good in your email, and all your questions make sense.
Sorry to disappoint you that the project is not available.

Good luck if you try applying to another organisation!

On Fri, Mar 25, 2022 at 5:41 PM Israa Odeh  wrote:
>
> Dear Flashrom Org,
>
>
>
> While I was looking for a GSOC contribution that appeals to my interests and 
> attracts my attention. I noticed your GSOC project ideas for Flashrom, and 
> specifically, the task labeled as "Modernize the flashrom website", which I 
> found quite interesting. Generally, I enjoy web development using CSS, HTML, 
> JavaScript, and PHP, and I'm willing to learn new skills, work with various 
> frameworks, and learn about other helping platforms to enhance my abilities.
>
>
>
> However, I would like to gain more details about what this project idea 
> requires in minute details so that I could prepare an appropriate proposal 
> and a good plan if it is suitable to me.
>
>
>
> Please Kindly, provide me with additional information about the requirements.
>
>
>
> Examples of a bunch of details that I need to know:
>
> - Who will be the mentors? (This isn't clarified for each task separately).
>
>
>
> - What are the expected outcomes you hope to accomplish with this task?
>
>
>
> - Do you mean specifically that you need to improve the front-end? (Is it 
> specifically a front-end improvement?)
>
>
>
> - Must the design be responsive?
>
>
>
> - Are there any predetermined languages or frameworks to use?
>
>
>
> - Could you clarify what do you mean by saying "However, we have to find out 
> what we need and which framework supports what. Then, various frameworks need 
> to be evaluated and we need a plan on how to migrate to the new site."
>
>
>
> I'd appreciate hearing the required details from you.
>
> Kind Regards
>
> Israa Odeh.
>
>
>
>
>
> Sent from Mail for Windows
>
>
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions regarding Easy project and GSoC

[Anastasia Klimchuk]

I realised one thing that I need to answer:

> I have completed a rough draft for my proposal, can someone review it?

So just to be very very clear: the answer is no, we won't be
pre-reviewing your proposal(s). You will submit them to the gsoc
website, they will go through the system and then will come to us. And
we will read all the proposals! :)

Felix answered this correctly, but I see that my message was vague, so
I decided to clarify.

You are welcome to ask questions, if you have any about the project,
so that you can write the proposal yourself.
Good luck!

On Tue, Mar 29, 2022 at 8:18 PM Thomas Heijligen  wrote:
>
>
>
> On 26 March 2022 05:44:56 WET, Aarya Chaumal  wrote:
> Hi Aarya,
>
> >I performed (read, write, erase) on specific regions of the flash using the
> >layout file. Do the regions in the layout file have to be exclusive or they
> >can overlap?
> A flashrom layout region is just a name with a start and end address. There 
> are no checks for overlapping regions. The parsing of a layout file is done 
> by layout_from_file() in layout.c
>
> -- Thomas



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions regarding Easy project and GSoC

[Anastasia Klimchuk]

I can add a few bits from me.

You can only do one project as gsoc, because the rules say so:
https://summerofcode.withgoogle.com/rules
See 7.3.b

The rules also say that you can submit up to 3 proposals, but only one
of them we can select. In theory, you can write 2 proposals for 2
projects that you like, and submit both, but we will choose only one
anyway. In any case writing a proposal is an effort, and writing two
of them is double of that effort.

Yes, a project will have a Mentor guiding it, and you will be talking
to Mentor regularly.
But also, in case you have some generic questions (about the process
for example), you can also ask me or Felix, we take care that
everything is running.

> I have completed a rough draft for my proposal, can someone review it?

I am actually thinking about it, maybe it's ok? Let me think about it
and check the rules :)
I assume you are talking about a draft for a project proposal (by our template).

Importantly, your actual application you will be submitting *not to us
directly*, but to gsoc website. It will go through the system and then
come to us, but not from your hands directly. Make sure you read
official guidelines on how to submit the application! :)

On Sat, Mar 26, 2022 at 6:36 PM Felix Singer  wrote:
>
> On Sat, 2022-03-26 at 10:57 +0530, Aarya Chaumal wrote:
> [...]
> > As I said before I am interested in "Optimize Erase-Function
> > Selection" and "Fix Endianness Issues" (I still cant decide which one
> > to choose, kinda wanna do both if possible).
>
> Glad you like them! Though, you can't do both during GSoC, since each
> of them will be a significant time commitment for you. But if you are
> still motivated after GSoC, you can do the other one later if it is
> still available :)
>
>
> > I have understood what is the aim of the projects and also have some
> > idea as to how to go about it.
> >
> > I have read the proposal template and have some questions:
> > In the project info section, do I have to write the same as given in
> > the projects idea list, or do I write what I have understood (in the
> > short and long descriptions)?
>
> That point is more related to the project proposal. Seems like we mixed
> it up with the application template :)
>
> However, we expect our applicants to describe the project they want to
> do in their own words to see if they understood it.
>
>
> > Also, what is expected in the project breakdown?
>
> We would like to see that our applicants made realistic and serious
> thoughts about their projects. So we expect you give an overview about
> your work schedule. You should define small steps and elaborate them
> weekly or fortnightly.
>
> For example:
>
>  Week 1: First, I will start with reworking thing XY and ...
>  Week 2: When cleaning up thing XY is finished, then I will work on
>  another thing.
>  Week 3: Depending on how the another thing was solved, I will do this
>  or that.
>
> Of course this schedule won't fixed and this doesn't have to be
> perfect, because new problems can appear or you might get a better idea
> for something. We just want to see that you made thoughts about the
> project and that you have a somewhat realistic schedule on how to do
> it.
>
> Also, this helps you to keep track of your own work and your schedule
> before and during GSoC. The past showed that people underestimated
> their projects or the workload per week and then it got stressful for
> them.
>
>
> > Will I be doing the project alone or the mentor(s) will be guiding
> > me?
>
> You will have at least one mentor on your side guiding you and you will
> have weekly meetings with them. So if you have any questions, problems
> or anything you would like to discuss, then they are your contact
> persons.
>
>
> > I have completed a rough draft for my proposal, can someone review
> > it?
>
> Well, we can answer questions related to the project or help
> understanding what hasn't been understood yet, but we won't review your
> application :)
>
>
> // Felix



-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Gatekeeping, ACLs and Review Rules

[Anastasia Klimchuk]

Hello!

> and I vote 100% against it. FWIW, this feature wakes our worst in-
> stincts. No matter how convinced we are that review is also for our
> own good, getting a commit merged always feels rewarding. And many
> people act like it's a necessity to set the resolved tick to gain
> that reward. I've seen people doing so with every single comment they
> wrote since day 1 when this feature was activated for coreboot. Let's
> not repeat every mistake made there.
>
> Also, today Gerrit warns about unresolved comment threads when one
> tries to submit. Enforcing it brings a marginal convenience but makes
> the review process less friendly in my experience.
>
> Sometimes comment threads are opened after review. So the `merged`
> status never implies all-comments-resolved. And that's not bad, IMHO.
> Sometimes things come up after review and Gerrit makes it easy to
> continue to discuss changes even after they are merged.

I have mixed feelings about this. On one hand, I understand what you
are saying about worst instincts, especially since you are saying you
observed examples how the feature can be workarounded. On the other
hand, it seems logical to me to have two types of comments: major ones
that need to be resolved before merging the patch, and everything else
(non-blocking).
Also, I am totally fine to leave as is: my own workflow won’t change.
I learned over the years that people have a variety of opinions about
yellow and grey comments, my workflow is trying to cover all of that
anyway :)

> There also seems to be a misunderstanding about patches. Some people
> seem to believe that every patch should get merged eventually.

I think, you gave a perfect explanation to this just above: “getting a
commit merged always feels rewarding”

> IMO, problematic patches should not be escalated but avoided in the
> first place. In our wiki it says in multiple places that one should
> discuss things on the mailing list early so nobody gets frustrated
> later. Such problematic reviews is exactly why it's stated there.
> Open-source development is nothing new. Many problems have been fixed
> in the past already. Please always encourage everybody to try the
> established ways before experimenting with new ones.

That’s all correct, for sure! But sometimes, established ways do not
work (for whatever reasons). And boom, we have a problematic patch. It
should not exist, but here it is. You called this “escalation” but
what if it is only reviewers discussing, it is not an escalation, it’s
the same people who are on the patch, just talking instead of typing?
And yes, if everything goes normally , it’s not needed.

Re: encouragement, I always do what I can!

> If we don't revert first, it
> will create pressure to fix things right now (which may break things
> again).

Agree with that! I agreed with that from the very beginning :)

> something like "Do you want to write
> that for upstream, there's the development guidelines: https://...;.

Believe it or not, guidelines are something that we recently discussed
(guidelines for people who send patches upstream). But I need to work
on this a bit, I will tell later!

However one topic I am not sure how to guide is: gerrit comments. The
only thing I understand by now, there are various opinions on gerrit
comments.

Also, returning back to initial questions, an idea of having a
Reviewers group for flashrom.
Does this look good for everyone?
This comes together with a question: what are criteria to add someone
to Reviewers and Committers?

This probably needs some brainstorming, so I am going to start, I give
it 5 mins, everything that comes to mind:

Number of patches owned [for last X months/years]
Number of patches reviewed [for last X months/years]
Number of patches merged [for last X months/years]
Last time the patch was reviewed
Last time patch was send to review
Last time patch was merged
How long active on the project
Any topics on the mailing list
Reachable via email or channel
…..


On Fri, Mar 18, 2022 at 2:44 AM Nico Huber  wrote:
>
> Hi Anastasia,
>
> On 17.03.22 12:32, Anastasia Klimchuk wrote:
> >> For example, the flashrom project doesn't require that all comments
> >> be resolved before merge.  That can be enabled if you'd like, but currently
> >> it isn't.
> >
> > Oh this explains! I was wondering where those “patches merged with
> > unresolved comments” are coming from. I am 100% voting for this setting to
> > be enabled. It does not prevent from just clicking Ack on all comments, if
> > needed. But at least, comments won’t be lost unintentionally.
> >
>
> and I vote 100% against it. FWIW, this feature wakes our worst in-
> stincts. No matter how convinced we are that review is also for our
> own good, getting a commit merged always feels rewarding. And many
> people act like i

[flashrom] Re: Questions regarding Easy project and GSoC

[Anastasia Klimchuk]

Hi Aarya,

I fully agree with Simon, you are doing great!

I have just submitted the first one out of your patches, congrats! Well
done :)
Few more of them seem to be almost ready, just some comments about commit
messages need to be resolved.

Don't be surprised that you are getting so many comments about commit
messages. The reason is, once a patch is submitted, commit message stays in
history forever and it cannot be changed. So it is very important to get it
right.
Sometimes one need to go through the history of commits, to understand why
some code was written as is - and commit message should be able to explain
why.

On the project side, read our project proposal template

(if you haven't already) and see if you have any questions about it. Also
you can prepare questions that you would ask the Mentor.

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Questions About Flashrom Of Gsoc

[Anastasia Klimchuk]

Hi, apologies for a long delay in reply!

"in the tree" means in the git tree. Which means, you create a git
repository locally (flashrom repository) and then run scan-build inside it.

On Mon, Mar 14, 2022 at 10:26 AM Hui Xiang  wrote:

> Hi Anastasia,
>
>
>
> Thanks for your reply and suggestions.
>
>
>
> >You can do one of "Fix scan-build issues".
>
>
>
> In the description of this task, it said, “Run scan-build in the tree.” I
> am a little confused about the words “in the tree.” How can I find it?
>
>
>
> Regards,
>
> Hui
>
>
>
>
>
> *From:* Anastasia Klimchuk 
> *Sent:* 13 March 2022 00:01
> *To:* flashrom ; Hui Xiang 
> *Subject:* Re: [flashrom] Questions About Flashrom Of Gsoc
>
>
>
> > When I browse all the code on GitHub, are there any suggestions?
>
>
>
> You can do, for example, like this.
>
> Once you build flashrom, you can run help command
>
>
>
> flashrom -h
>
>
>
> This is not doing anything with hardware, just showing help information.
> Specifically, all command line operations, arguments and what they are
> doing.
>
> The code which is an entry point for help command (and for all the other
> command line operations) is in cli_classic.c file.
>
> First of all, read help information, see what operations are available.
> Then you can start with cli_classic.c , pick some operation and explore the
> code which implements it.
>
>
>
> > What further preparation need I take if I wish to join Gsoc this year?
>
>
>
> I see that the Easy project that you picked might already be done (as
> Simon said). You can do one of "Fix scan-build issues". You will learn how
> to work with Gerrit, and this is critical since we use Gerrit on flashrom.
>
>
>
> Good Luck!
>
>
>
> On Sat, Mar 12, 2022 at 9:49 AM Hui Xiang  wrote:
>
> Hi Anastasia,
>
>
>
> Thank you for your response and recommendations. In the future, I will do
> that.
>
> When I browse all the code on GitHub, are there any suggestions? What
> further preparation need I take if I wish to join Gsoc this year?
>
>
>
> Regards,
>
> Hui
>
> *From:* Anastasia Klimchuk 
> *Sent:* 11 March 2022 08:54
> *To:* Hui Xiang ; flashrom 
> *Subject:* Re: [flashrom] Questions About Flashrom Of Gsoc
>
>
>
> Hi Hui,
>
>
>
> First of all, I wanted to say, you replied to me only and not to the
> mailing list (and I only noticed now). Most likely you clicked the "Reply"
> button instead of "Reply All". I am adding the mailing list back, but for
> future please keep in mind to Reply All.
>
> The most important reason is that if you send your questions to the
> mailing list, then everyone in our community can help you! Which is really
> good. You will have various questions, and you never know who is the best
> person to answer. So, pay attention that the mailing list is on the To line
> ;)
>
>
>
> Some things I can answer:
>
>
>
> >> The platform Gerrit is mentioned in the "Development Guidelines." All
> I know about it is that it is a code management tool. Are there any
> tutorial videos or articles that I can use to learn more about Gerrit?
>
>
>
> Gerrit is also a code review tool. Gerrit has an official website with
> lots of presentations, look here
> https://www.gerritcodereview.com/presentations.html , hopefully that's
> useful!
>
>
>
> >> I went to GitHub's official Flashrom mirror.
>
>
>
> You can browse all code on GitHub, no problem, and yes it can be a
> convenient way to browse. Just keep in mind GitHub is a mirror, so that's
> pretty much only for browsing code. When you start with trying to make
> changes by yourself, you need to set up flashrom git repository locally.
> When you come to that point, open
> https://review.coreboot.org/admin/repos/flashrom and choose your desired
> method to clone the repository. Supported methods are HTTPS and SSH. The
> same method will also be used when you push your changes to Gerrit later.
>
>
>
> >> My current devices are a Windows 11 laptop (processor 11370H, Tiger
> Lake-H35) and a Mac. Is it possible for me to try out some patches on my
> computer? Also, could you provide me with any resources or introductions to
> chip packaging (DIP32, PLCC32, DIP8...)?
>
>
>
> I am wondering if someone else can take these questions? We need community
> help on this :)
>
>
>
> Thanks!
>
>
>
>
>
>
>
>
> --
>
> Anastasia.
>


-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flashrom Dev Meeting once a month?

[Anastasia Klimchuk]

REMINDER:

Next Dev Meeting is in 1.5 days, please don't forget to convert to your
local time.
---
23th March 2022, 21:00-22:00 UTC+0
---
Meeting id and agenda is added to meeting notes
<https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing>
document.



On Wed, Mar 9, 2022 at 10:08 AM Anastasia Klimchuk 
wrote:

> Reminder: this is happening tomorrow! 9th March 21.00-22.00 UTC+0
> Meeting id is added to meeting notes
> <https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing>
> document.
>
> On Wed, Mar 2, 2022 at 5:48 PM Anastasia Klimchuk 
> wrote:
>
>> ATTENTION ATTENTION
>>
>> We are locking the date and time for the first Flashrom Dev Meeting:
>>
>> -
>> *9th March (Wednesday) 21:00-22:00 UTC+0*
>> -
>>
>> Please don't forget to convert to your local time! :)
>>
>> Meeting room id will be organised very soon and added to the meeting
>> notes
>> <https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFsKqw/edit?usp=sharing>
>> document.
>>
>> On Tue, Mar 1, 2022 at 5:54 PM Felix Singer 
>> wrote:
>>
>>> On Thu, 2022-02-24 at 19:51 +1100, Anastasia Klimchuk wrote:
>>> > Monday 21:00-22:00 UTC+0
>>> > Wednesday 21:00-22:00 UTC+0
>>> >
>>> > I will just make a suggestion: what about 9th March (Wednesday)
>>> > 21:00-22:00 UTC+0 ?
>>>
>>> +1 Sounds good to me :)
>>>
>>>
>>>
>>> > #4 Software
>>> >
>>> > Can we use Google Meet for the first meeting and see how it goes?
>>> > Once the room is created, we will link it to Meeting Notes, so it
>>> > will be easy to find it.
>>>
>>> Yes, let's use Google Meet for now and see how that works.
>>>
>>> // Felix
>>>
>>>
>>
>> --
>> Anastasia.
>>
>
>
> --
> Anastasia.
>


-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Release preparations

[Anastasia Klimchuk]

Thank you for the explanations! Really helpful.

I am trying to understand the mechanics.

“This is also why I suggested that we can drop suspicious
code from a release branch (i.e. we could branch 1.3.x now
and then delete code on that branch without affecting master).
Then the freeze might be over really quickly.”

This option would mean all the items from the first list are reverted in
v1.3?
And then they, hopefully, all get fixed to the time of v1.4?
(correct me if I am wrong)

Then that means on the other end there is an ideal scenario where all the
items from the first list are fixed (on master) and then v1.3 happens?

And also a scenario in between when some of the items are fixed, but not
all of them?

Which of these scenarios has minimum time to freeze master, and which one
takes second place? I am asking because I fully agree with you, it seems
just as you said “a very desperate measure”... so I am worried this may
create a drama :\

We have already created 5 bugs as “flashrom release blockers” in our
internal bug tracker (the only reason they are created in internal one is
because flashrom bug tracker is not ready yet). There is no secret info
there at all. That’s for all the items that are missing documentation.
It is not a hasty activity, we want to help! Release is important.
And especially the items which say “missing documentation”, it’s a
no-brainer, needs to be fixed.

“My latest idea about this is that we could add an option (e.g.
`inofficial`) and a whitelist of known working platforms. Such that
one would have to literally state they want an inofficial binary to
build on a platform with unknown status.”

Looks fine, let’s keep it unofficial (if it really is). Let’s just not
delete it :)

“I can work on that unless someone else wants the task.”

Thanks Martin! There is a patch currently for man page:
https://review.coreboot.org/c/flashrom/+/62768
But did you mean more than that?

On Fri, Mar 18, 2022 at 2:56 AM Nico Huber  wrote:

> On 13.03.22 16:28, Nico Huber wrote:
> > On 13.03.22 08:28, Anastasia Klimchuk wrote:
> >>> I suggest that we freeze the master branch for everything that is
> neither
> >>> a fix nor on the list (or a similar case that I missed)
> >>
> >> But how can we freeze master… that would mean no one can do any work?
> Maybe
> >> I am missing something?
> >
> > No you didn't miss anything :) it would be a very desperate
> > measure. However, I see no other solution to make progress
> > again without forking or further stalling a release. And
> > after 2 years I think the project has waited long enough.
>
> Sorry folks, I didn't mean to provoke any hasty activity to fix the
> listed problems. Rather to push us to talk about what we should fix
> before a release and what features we could do without in a release.
> If we'd wait for everything to be fixed at snail pace, I fear people
> would give up before another release happens (I would). Not to mention
> that people will continue to push more controversial patches in the
> meantime.
>
> Nico
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>


-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org