flashrom

flashrom@flashrom.org

1 participants
9187 discussions

how to enable the internal programmer
by Selva Harris 16 May '22

16 May '22

Hi, I have an Intel Apollo lake board. I want to read the SPI chip. When I run 'flashrom -p internal', this is the message I get: flashrom v1.2-735-gb728f4b on Linux 4.5.5-300.fc24.x86_64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Error: Unknown programmer "internal". Valid choices are: dummy, serprog, buspirate_spi, rayer_spi, pony_spi, linux_mtd, linux_spi. Please run "flashrom --help" for usage info. Thanks in advance, Selva

2 2

[PATCH] Add voltage data for chips
by Chinmay Lonkar 11 May '22

11 May '22

From: ChinmayLonkar <chinmay20220(a)gmail.com> This patch adds voltage data for following chips: * Intel 28F002BC/BL/BV/BX-T * Intel 28F004B5/BE/BV/BX-B * Intel 28F004B5/BE/BV/BX-T * Intel 28F008S3/S5/SC * Intel 28F400BV/BX/CE/CV-B * Intel 28F400BV/BX/CE/CV-T * Micron/Numonyx/ST M25P40-old * SyncMOS/MoselVitelic {F,S,V}29C51002T * Winbond W29C010(M)/W29C011A/W29EE011/W29EE012 * Winbond W29C010(M)/W29C011A/W29EE011/W29EE012-old Change-Id: I42bc546e03a899086c034c026231955088a7d400 Signed-off-by: Chinmay Lonkar <chinmay20220(a)gmail.com> --- flashchips.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/flashchips.c b/flashchips.c index d155b24..f9cb0cd 100644 --- a/flashchips.c +++ b/flashchips.c @@ -8112,6 +8112,7 @@ const struct flashchip flashchips[] = { }, .write = write_82802ab, .read = read_memmapped, + .voltage = {4500, 5500}, }, { @@ -8139,6 +8140,7 @@ const struct flashchip flashchips[] = { }, .write = write_82802ab, .read = read_memmapped, + .voltage = {4500, 5500}, }, { @@ -8166,6 +8168,7 @@ const struct flashchip flashchips[] = { }, .write = write_82802ab, .read = read_memmapped, + .voltage = {4500, 5500}, }, { @@ -8189,6 +8192,7 @@ const struct flashchip flashchips[] = { .unlock = unlock_28f004s5, .write = write_82802ab, .read = read_memmapped, + .voltage = {2700, 3300}, }, { @@ -8217,6 +8221,7 @@ const struct flashchip flashchips[] = { }, .write = write_82802ab, .read = read_memmapped, + .voltage = {2700, 3600}, }, { @@ -8245,6 +8250,7 @@ const struct flashchip flashchips[] = { }, .write = write_82802ab, .read = read_memmapped, + .voltage = {2700, 3600}, }, { @@ -10521,6 +10527,7 @@ const struct flashchip flashchips[] = { .unlock = spi_disable_blockprotect_bp3_srwd, .write = spi_chip_write_256, .read = spi_chip_read, + .voltage = {2300, 3600}, }, { @@ -16884,6 +16891,7 @@ const struct flashchip flashchips[] = { }, .write = write_jedec_1, .read = read_memmapped, + .voltage = {4500, 5500} }, { @@ -16910,6 +16918,7 @@ const struct flashchip flashchips[] = { }, .write = write_jedec_1, .read = read_memmapped, + .voltage = {4500, 5500} }, { @@ -18607,6 +18616,7 @@ const struct flashchip flashchips[] = { }, .write = write_jedec, .read = read_memmapped, + .voltage = {4500, 5500}, }, { @@ -18630,6 +18640,7 @@ const struct flashchip flashchips[] = { }, .write = write_jedec, .read = read_memmapped, + .voltage = {4500, 5500}, }, { -- 2.25.1

2 2

Flashrom sp_stream_buffer_op() API issue
by Chinmay Lonkar 07 May '22

07 May '22

Hi, I'm trying to fix the build errors of flashrom and came across an API error "Argument with 'nonnull' attribute passed null" which occurred in memcpy() function called inside sp_stream_buffer_op() in file serprog.c. We are passing the third argument of sp_stream_buffer_op() as NULL which gets passed on to the second argument of memcpy() and it expects that argument to be nonnull. Can anybody please provide me with the info and docs for knowing exactly what sp_stream_buffer_op() function does? Also, should we report an error when the third argument passed in the sp_stream_buffer_op() is NULL? Thank You! Regards, Chinmay Lonkar

2 2

flashrom dev meeting notes 5.05.22
by Felix Singer 05 May '22

05 May '22

# 5th May 2022, 6:00 - 7:00 am UTC+0 Attendees: Anastasia, David, Edward, Felix, Nico, Nikolai, Thomas ## Decisions Summary * Thomas gets submit rights * We want a separate reviewers group for flashrom so that reviewers are not mixed across different projects * Different tags for bug IDs are needed so that Google IDs (non-public) are not mixed with tickets from the flashrom issue tracker (public) * The mailing list should be used more for design discussions ## Agenda * [aklm] I wanted to remind that we have an ongoing item “to figure out criteria to give people submit rights”. It was raised on the very first meeting. I think it is in many people's heads. * There is a thread on the mailing list “Gatekeeping, ACLs and Review Rules” ([link](https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/threa… )). The topic is in scope of the thread. Currently the last message is mine, I can’t just talk to myself on the topic. Please share your thoughts! * In the absence of criteria I want to nominate Thomas to get submit rights. This is also an idea from the very first meeting. * In addition to commit stats that Martin gave in the first meeting, I have more points * Thomas is active on the project for a while, * he will be a gsoc Mentor, teaching our new contributors * Reachable and responding on the irc, by email, mailing list * Yes, no objections! * We need rules for this. Not too many people should just get submit rights so that we can keep track. * Separate Reviewers group for flashrom, everyone agrees. * Nik: better have a restricted group for Reviewers, and everyone can submit. * Let’s give Thomas submit rights. Congrats! * Anything that’s left to discuss from the item: “(in case somebody knows) What is Google’s current strategy to avoid repeating mistakes of the past?” * [dhendrix] Is this the kind of finger pointing that Edward mentioned above? At this point, CrOS has proved more than happy to move upstream. The Github mirror is probably more of a concern. Perhaps upstream should consider how to get developers to choose upstream rather than the Github mirror or some other fork. * [Nico] Pointing at Google, actually. If one company forks and later wants their code upstream without proper review, something seems wrong. As if they never reflected about the problems. * [aklm] I am not sure we are on the same page on what are “mistakes of the past”. Everyone has their own idea on what the mistakes were. I can start from myself. From my observations, converging the code was considered a purely technical task, and so it was done as a technical task. However, converging the code means converging the people/the teams, converging very different workflows and work cultures. This does not seem to be thought through or ever discussed, and to me this is a mistake. * Thomas : put GOOGLE_BUG tag and BUG is for public issue tracker * Edward BUG=g:1234566,b:544 * Edward: happens more on board bringup * Nikolai: maybe keep b: prefix for google bugs BUG=b:google_id,f:flashrom_id * Felix : [https://doc.coreboot.org/infrastructure/services.html#issue-tracker](https:… * [quasisec] I am also unclear how CrOS convergence had really much of an impact on upstream considering >99% of the work was adjusting the CrOS fork to realign with upstream. Only an extremely small amount of alignment was in the form of upstream commits, e.g., missing raiden_debug and some unfortunate part of sb600spi. Is there a specific area that stands out? * [Nico] No idea if related to the original reasons for the fork, but that the convergence is stalling new releases for years stands out pretty much. * [Nico]: How can we teach developers who got to know the [Chrome OS] fork first about the upstream project (if not during review)? * [PatrickG] Once upstream-first is established, downstream patches aren’t reviewed anymore and redirected to upstream. * [quasisec] I am not sure anyone really “got to know the fork” as such. The problem was the fork was treated as a means to an end. Hence all the additional investment in improving flashrom such as life-cycle API and unit-testing to name some recent examples. Other examples include upstreaming additional hardware support such as lspcon, mst’s and raiden or later generation PCH rev’s. * [quasisec]: Regarding “teaching” can you elaborate on what this actually means as I think there is more than one dimension to the intent of that. * [Nico] I see a lack of a forum to teach people about the project. Because the mailing list is basically rejected by Google developers (with exceptions of course), and people ask to keep comments on Gerrit to very specific “actionable” items, where should we teach people about the project, how we do things and what to focus on? Etc. * [quasisec]: No one “rejected” anything, the commit you refer to Nico is here [https://review.coreboot.org/c/flashrom/+/62768](https://review.coreboot.org… and the issue is the tone of the review. I’ll leave others to judge. * Nico: we need to use mailing list for design discussions, before starting the work * Edward: how to decide what is big and what is small? * **dunning kruger effect** * Nico: early engagement before writing code. * New programmers should be discussed first. * Infra change * Change touching multiple layers * aklm: What happens when the developer has already started? * Threshold to decide whether to send a patch without any prior discussion or conversation: are you ok to re-write the patch if the idea is not supported as is? * Price of the mistake? * quasisec: how to make the price not so high that we don’t scare people away also? * Felix: mention in the guidelines , recommend to discuss on mailing list first * Aklm: this is already recommended on the guidelines * Edward: developers think in code first, they think of design and write some draft code * Nik: whatever tool works best * Felix: An account is needed for Gerrit and thus not everyone is able to join the discussion. * Aklm: for a patch you need to know whom to add as reviewers. On the mailing list, you just post, everyone reads. * quasisec: How to make things like adding programmers a bit more template’ty? Common pattern guidance? Make flashrom API’s better? * Edward: can the code say “file a bug” instead of “write to the mailing list”? * Nico: it could be another mailing list? * Edward: prefix in the subject line, so that people can filter if they want, or not do anything. Create a bug, bug updates are sent on the mailing list. User has a handle on the issue. * Felix: people need an account to create bugs on redmine, but for the mailing list no account is needed.

1 0

Updated invitation: Flashrom Dev Meeting (monthly) @ Every 2 weeks from 4pm to 5pm on Thursday (AEST) (flashrom@flashrom.org)
by aklm＠chromium.org 04 May '22

04 May '22

This event has been changed. Title: Flashrom Dev Meeting (monthly) Monthly meeting of Flashrom project developers. Meeting notes doc: https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZ… When: Every 2 weeks from 4pm to 5pm on Thursday Eastern Australia Time - Sydney Joining info: Join with Google Meet https://meet.google.com/iuf-mtri-zva?hs=224 Join by phone (AU) +61 2 9051 6791 (PIN: 304642402) More phone numbers: https://tel.meet/iuf-mtri-zva?pin=9271993818880&hs=0 Calendar: flashrom(a)flashrom.org Who: * aklm(a)chromium.org - creator * felix.singer12(a)gmail.com * david.hendricks(a)gmail.com * quasisec(a)google.com * nico.h(a)gmx.de * Martin Roth * src(a)posteo.de * martonmiklosqdev(a)gmail.com * piotr.krol(a)3mdeb.com * Maciej Pijanowski * michal.zygowski(a)3mdeb.com * th3fanbus(a)gmail.com * stefan.k.reinauer(a)gmail.com * nartemiev(a)google.com * arthur(a)aheymans.xyz * flashrom(a)flashrom.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmVscGY2cjNsdTZw… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account flashrom(a)flashrom.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Updated invitation: Flashrom Dev Meeting (monthly) @ Every 2 weeks from 4pm to 5pm on Thursday (AEST) (flashrom@flashrom.org)
by aklm＠chromium.org 04 May '22

04 May '22

This event has been changed. Title: Flashrom Dev Meeting (monthly) Monthly meeting of Flashrom project developers. Meeting notes doc: https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZ… When: Every 2 weeks from 4pm to 5pm on Thursday Eastern Australia Time - Sydney Joining info: Join with Google Meet https://meet.google.com/iuf-mtri-zva?hs=224 Join by phone (AU) +61 2 9051 6791 (PIN: 304642402) More phone numbers: https://tel.meet/iuf-mtri-zva?pin=9271993818880&hs=0 Calendar: flashrom(a)flashrom.org Who: * aklm(a)chromium.org - creator * felix.singer12(a)gmail.com * david.hendricks(a)gmail.com * quasisec(a)google.com * nico.h(a)gmx.de * Martin Roth * src(a)posteo.de * martonmiklosqdev(a)gmail.com * piotr.krol(a)3mdeb.com * Maciej Pijanowski * michal.zygowski(a)3mdeb.com * th3fanbus(a)gmail.com * stefan.k.reinauer(a)gmail.com * nartemiev(a)google.com * arthur(a)aheymans.xyz * flashrom(a)flashrom.org * c-d.hailfinger.devel.2006(a)gmx.net Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmVscGY2cjNsdTZw… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account flashrom(a)flashrom.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

MX25L12833F
by Jon Bowen 02 May '22

02 May '22

2 1

Found Generic flash chip "unknown SPI chip (REMS)" (0 kB, SPI) on serprog.
by Gabriel Lopes da Silva Saraiva 01 May '22

01 May '22

The CHIP IC is: 25QL128CSIG I submitted a ticket on github, but but the BOT shut down, I tried to submit it a second time. sudo flashrom -p serprog:dev=/dev/ttyACM0:4000000 -r file-to-save.binflashrom unknown on Linux 5.11.0-46-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). serprog: Programmer name is "stm32-vserprog" serprog: requested mapping AT45CS1282 is incompatible: 0x1080000 bytes at 0x00000000fef80000. serprog: requested mapping GD25Q256D is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25LP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25WP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25L25635F/MX25L25645G is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U25635F is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L51235F/MX25L51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L1G45G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q00A..1G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q00A..3G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q256..1E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q256..3E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q512..1G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping N25Q512..3G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QL01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QU01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QL02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QU02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QL256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QU256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QL512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QU512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping S25FL256S......0 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping S25FL512S is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping W25Q256.V is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JV_M is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256.W is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JW_DTR is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q512JV is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping XM25QH256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping XM25QU256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. Att, Utherbone (Gabriel) <http://speedtec.gq/> <http://speedtec.gq/> <http://gabrielsaraiva.xyz/>

2 1

[flashrom - Bug #352] (New) test issue for mailing list
by Felix Singer 25 Apr '22

25 Apr '22

Issue #352 has been reported by Felix Singer. ---------------------------------------- Bug #352: test issue for mailing list https://ticket.coreboot.org/issues/352 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2022-04-25 ---------------------------------------- This is a test issue for the flashrom mailing list. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Unsupported chip AT25SF128A
by Staffan Ulfberg 23 Apr '22

23 Apr '22

Datasheet at: https://www.dialog-semiconductor.com/sites/default/files/2021-02/DS-AT25SF1… Probing for Unknown SFDP-capable chip, 0 kB: SFDP revision = 1.0 SFDP number of parameter headers is 2 (NPH = 1). SFDP parameter table header 0/1: ID 0x00, version 1.0 Length 36 B, Parameter Table Pointer 0x000030 Parsing JEDEC flash parameter table... 3-Byte only addressing. Status register is non-volatile and the standard does not allow vendors to tell us whether EWSR/WREN is needed for status register writes - assuming EWSR. Write chunk size is at least 64 B. Flash chip size is 16384 kB. Block eraser 0: 4096 x 4096 B with opcode 0x20 Tried to add a duplicate block eraser: 4096 x 4096 B with opcode 0x20. Block eraser 1: 512 x 32768 B with opcode 0x52 Block eraser 2: 256 x 65536 B with opcode 0xd8 done. SFDP parameter table header 1/1: ID 0x1f, version 1.0 Length 12 B, Parameter Table Pointer 0x000060 === SFDP has autodetected a flash chip which is not natively supported by flashrom yet. All standard operations (read, verify, erase and write) should work, but to support all possible features we need to add them manually. You can help us by mailing us the output of the following command to flashrom(a)flashrom.org: 'flashrom -VV [plus the -p/--programmer parameter]' Thanks for your help! ===

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom