flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Help required for GD25LB64C
by CyberPK 11 Feb '18

11 Feb '18

Hello, I'm trying to read and write the flash memory into a GD25LB64C which is automatically recognized as GD25LQ64C. I'm using a pickit2 setting 1.8V and flashrom 1.0 compiled from source release. I'm using the -VVV flag, but the read process remains stuck in reading and the writing process remains stuck in "reading old flash chip contents". I've also tried to erase the content using the -E flag in addition to the verbose -VVV flag and I can see the slow advancements through the addresses appearing to n the screen. But I'm still unable to read or write. What I can do? Any idea? Regards

1 0

Re: [flashrom] CrOS flashrom compatibility and upstreaming of CrOS features
by Nico Huber 08 Feb '18

08 Feb '18

Hi David, sorry for taking that long. I guess I was waiting for more people to chime in (I'll still not abandon that hope, generally). On 25.01.2018 08:12, David Hendricks wrote: > On Wed, Jan 24, 2018 at 10:36 AM, Nico Huber <nico.h(a)gmx.de> wrote: > >> Hey folks, >> >> during review of commits that port per-region file arguments [1] from >> CrOS flashrom over here, we ran into a discussion about the command line >> interface changes. The basic question that arose is >> >> Do we want to maintain full CLI compatibility to CrOS flashrom? >> >> This would have the upside, that it would ease remerging of the two >> flashrom versions (in some unknown future). And anybody currently >> using CrOS flashrom could transition more smoothly. OTOH, depending on >> how the compatibility is achieved, it might increase the costs for >> review and development heavily (for a project with 0 spare resources). >> >> To not have to discuss this each and every time when some non-trivial >> feature is ported over from CrOS, I'd like to have some opinions, how >> valuable CLI compatibility is to you all and how we want to achieve it. >> I have currently some alternative ideas in mind that I'll sketch below. >> Feel free to add other ideas or just to comment them. >> > > Option #2 seems pretty good IMHO. I suspect that CrOS will need to maintain > their legacy behavior for a while longer, but that does not need to hold > back upstream. We should of course improve our testing to avoid breaking > one or the other, at least without sufficient reason and time to adjust. Sounds good to me. Though for testing, we'd have to implement the CrOS compatible CLI rather sooner than later. > > Some background on this: CrOS currently maintains a separate CLI in their > tree, cli_mfg.c, specifically because the upstream CLI was not well-suited > for their manufacturing needs. Things like syntax changes, additional > options, verbosity, error handling, etc. were simply different from what > typical users expect. The partial read/write/verify syntax was developed to > meet specific needs of the manufacturing flow, and the write-protection > syntax was added specifically to address the way write-protection works on > Chromebooks. Stuff like "combining multiple files" was done to avoid > wasting valuable time on the assembly line and at runtime during normal OS > maintenance (yes, seconds really do matter). Hmmm, that valuable-time requirement is really something that would suffer with a wrapper script. So let's try to keep compatibility inter- nally. > > I'd still like to see CrOS converge with upstream so we share development > and testing efforts. It would also be great to have more device > manufacturers working with upstream. Having an alternate CLI coexist > alongside the "classic" CLI seems like a decent compromise IMO. Both sides > will benefit from a converged codebase, let's not make the CLI a blocking > issue. Agreed. Though, convergence will need effort on both sides... Nico

1 0

Adding support for "MX25U8032E"
by The_Raven Raven 05 Feb '18

05 Feb '18

Hi I made a Patch for adding "MX25U8032E" Chip. Hope the Patch is ok, i took the data from "MX25U1635E" and changed it to fit the "MX25U8032E". Tested (with arduino-serprog): - Probing - Reading (i readed the chip 3 times and make a diff, all diffs are same) - Erasing - Writing data1 - Writing data2 (overwriting) Important: The Vcc must be at max 2V, it does NOT work if Vcc is at 3.3V! This ends in read and write errors (data corruption)! Tested ;-) Greets

1 0

Pm25LD020(C) Chip tested -> OK
by The_Raven Raven 05 Feb '18

05 Feb '18

Hi I have tested Chip "Pm25LD020(C)" with Arduino (serprog). Chip works fine. Test Steps: - Readed - Erased - Written Data1 - Written Data2 (overwritten) Data1 and Data2 generated with "dd" from "/dev/urandom". Greets

1 0

Re: [flashrom] Github PRs
by Miklos Marton 03 Feb '18

03 Feb '18

Thank you for your answer David, I will follow your hint! Best regards, Miklos Marton 2018-01-30 22:54 keltezéssel, David Hendricks írta: > > Hi Miklos, > > Yes, coreboot's gerrit system is likely where the review will take > place. The github repository is a mirror of coreboot's flashrom > repository, however we recognize that a lot of people do development > on github so we work with pull requests as well. We also still have > patch submissions via e-mail. > > > You may receive comments to your pull request on github, however if > the patch is small enough (like PR33) then it might just be sent > directly to review.coreboot.org for final review before being merged > and ultimately mirrored in the github repo. > > > As usual the bottleneck is the amount of spare time reviewers have and > we've been juggling some large changes lately. We do appreciate the > contributions, and please feel free to nudge us if there is urgency or > if things simply linger for too long. > > ------------------------------------------------------------------------ > *From:* flashrom <flashrom-bounces(a)flashrom.org> on behalf of Miklos > Marton <martonmiklosqdev(a)gmail.com> > *Sent:* Tuesday, January 30, 2018 12:47:44 PM > *To:* flashrom > *Subject:* [flashrom] Github PRs > Hello flashrom developers! > > I have submitted two PRs to github (as the wiki mentions it is also a > possible contribution channel). > > Do I need to do anything else with that? I am not intended to seems to > be impatient I just would like to make sure that everything is in place > (this is my first contribution to flashrom this way). > > If I remember correctly the coreboot gerrit was used to do code review. > Is it going to be moved there or we will perform the code review at the > github? > > -- > Best regards, > Miklos Marton > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mail…

1 0

Re: [flashrom] Failed flash on Intel Bay Trail platform
by Quinn Plattel 03 Feb '18

03 Feb '18

Hi, I fixed the bad flash by using a Beaglebone Black and the OpenWRT screwdriver package (recommended by the coreboot project). Luckily, the board had pins directly to the flash via an SPI interface otherwise I might have had to use a Pomona clip. Quinn On 01/02/18 08:00, David Hendricks wrote: Hi Quinn, On Wed, Jan 31, 2018 at 5:01 AM, Quinn Plattel <q(a)bluetown.com<mailto:q@bluetown.com>> wrote: 13:56 < quinn> flashrom shows warning when reading or writing: BIOS region SMM protection is enabled! Did you have any luck with this? There might be a BIOS setting in the menu that allows you to disable the SMM lock, and as icon suggested on IRC the speed racer exploit might also be a feasible workaround. Another idea might be to try using coreboot on this board and simply not set the SMM lock bit until you need to do so ;-) There's a decent chance the Bayley Bay CRB implementation will work, though you may need to do some customization for your board: https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/intel/bayl… Best regards, Quinn Plattel Senior Network Engineer - BLUETOWN +45 53 70 85 67 - q(a)bluetown.com - Skype ID: dalilai Per Henrik Lings Allé 4, 3rd Floor - 2100 Copenhagen O - DK - +45 31 66 00 07 - www.bluetown.com [https://i.imgur.com/ZPkPX8i.png]<https://www.youtube.com/watch?v=AqERoJFeQNU>

1 0

Failed flash on Intel Bay Trail platform
by Quinn Plattel 01 Feb '18

01 Feb '18

Hi, Just tried to contact you guys via irc chat. Here is the transcript: 13:47 -!- Irssi: Join to #flashrom was synced in 1 secs 13:47 < quinn> hello, need help with a failed flash on an Intel Bay Trail platform. 13:48 < quinn> Detected flash chip is Winbond W25Q64.W 8192 kB, SPI mapped at phy addr 0xff800000 13:50 < quinn> System is an industry pc with model LEC-3030T 13:51 < quinn> Bios made by Aptio. 13:52 < quinn> dmidecode says Vendor is AMI with bios version 5.6.5 and release date 05/05/2016 13:52 < quinn> BIOS revision 5.6 according to dmidecode 13:54 < quinn> Re-reading the flash results in same size rom file but filled with "ff". 13:55 < quinn> I have the original rom saved. 13:56 < quinn> flashrom shows warning when reading or writing: BIOS region SMM protection is enabled! 13:57 < quinn> flashrom version used is v0.9.9-rc1-r1942 Regards, Quinn Best regards, Quinn Plattel Senior Network Engineer - BLUETOWN +45 53 70 85 67 - q(a)bluetown.com - Skype ID: dalilai Per Henrik Lings Allé 4, 3rd Floor - 2100 Copenhagen O - DK - +45 31 66 00 07 - www.bluetown.com [https://i.imgur.com/ZPkPX8i.png]<https://www.youtube.com/watch?v=AqERoJFeQNU>

2 2

Github PRs
by Miklos Marton 30 Jan '18

30 Jan '18

Hello flashrom developers! I have submitted two PRs to github (as the wiki mentions it is also a possible contribution channel). Do I need to do anything else with that? I am not intended to seems to be impatient I just would like to make sure that everything is in place (this is my first contribution to flashrom this way). If I remember correctly the coreboot gerrit was used to do code review. Is it going to be moved there or we will perform the code review at the github? -- Best regards, Miklos Marton

2 1

What's the intended license for flashrom?
by Nico Huber 30 Jan '18

30 Jan '18

Hi folks, I've just noticed that most of flashrom is licensed under GPLv2 + any later version, while about a third of the code base is GPLv2 only. I wonder if that is intentional, or if any of the license headers was just copy pasted and spread too much? Does somebody know any previous discussion on the topic? Nico

3 4

new whitelists for thinkpad r400, t500
by Leah Rowe 28 Jan '18

28 Jan '18

Hi, Here are some patches for flashrom, which adds whitelist for: ThinkPad R400 ThinkPad T500 Also Taurinus X200, which is a version of the ThinkPad X200 with libreboot, with boardinfo modified slightly

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom