flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Re: [flashrom] Namespace prefix for libflashrom
by Stefan Tauner 24 Apr '17

24 Apr '17

On Sat, 22 Apr 2017 11:16:18 -0700 David Hendricks <david.hendricks(a)gmail.com> wrote: > Thanks for getting this discussion going on the list, Nico. > > For reference, folks can view the proposed libflashrom.h at > https://review.coreboot.org/#/c/17946 to get a better idea for how these > prefixes will look in libflashrom functions and data structures. > > Also, let's add "fi_" for flashrom interface to the list of proposed > prefixes. > > My preferences (in order): > 1. lf_ > 2. flashrom_ > 3. fi_ > 4. fl_ > 5. flash_ > 6. fr_ > > IMO not only is "lf_" most intuitive, but the way the keys are spaced apart > comfortably on qwerty, dvorak, and colemak layouts and each character > (including the underscore) use a different hand to type. Same could be said > about fl_ with regards to keyboard layout. fr_ is awkward (keys vertically > adjacent) on qwerty and colemak, and fi_ is vertically adjacent on dvorak. > flash_ and flashrom_ are not bad but are obviously many more keystrokes. I value giving thoughts to details, but in this case I reside more with torvalds: "if your typing speed is the main issue when you're coding, you're doing something seriously wrong." In my opinion the prefix has to satisfy a number of requirements: - no ISO C(99/11) or POSIX violations - no easy collisions with other libraries or user functions - easily recognizable prefix for humans associated with the concept of libflashrom (i.e. some kind of abstraction to interact with NOR flash chips via different programmers) - reasonable short length to avoid overly long function names etc. based on the prefix > flash_ is pretty good - For the most part it flows well with functions such > as flash_image_read() and flash_image_write(), but is awkward with some > other stuff like "flash_set_log_callback()". If we're already typing >2 > letters I think we ought to just use flashrom_ as the prefix to be > complete, avoid awkward contexts, and avoid namespace conflicts (users > might want to use flash_ in their code). flash_ seems to me a bit too concrete... it gets (too) easily associated with the actual memory device and not so much to libflashrom IMHO. flashrom_ is quite long and would be associated with flashrom (the utility) and would make it harder to distinguishing the library from the program. libflashrom_ is probably too long but would at least transport the meaning best in my opinion. So... shorter but conveying the same meaning: - lflashrom, lfrom: meh - lflashr: would require a new awful website with flash chips dancing for no good reason ;) - lf: was already mentioned, I deem it a bit too short and ambiguous - fl: too easily misinterpreted as a flashrom function prefix IMHO - the aspect of being a library is important to me. - libf: would be in the tradition of short-named unix libraries (and seems to be unused actually as a library name), but does not really improve on lf and would make it look way too important than it is :) - lfr: was proposed in the wiki, possibly by myself - can't remember. This might be the optimal compromise: intuitive if you heard it once, probably quite unique and very short. - lfl: might also work if neither lfr nor lf are acceptable (but why would lfl then be :) Thus my favorites are basically - lfr_ - libflashrom_ - lf_ I'd love to hear some arguments about your preferences. Side note because I don't have the time yet to do proper reviews but I have briefly looked at nico's libflashrom.h: > struct flashprog; > typedef struct flashprog fl_flashprog_t; > struct flashctx; > typedef struct flashctx fl_flashctx_t; Please avoid type abstraction with no good reason (i.e. if there are no alternative implementations that need to be abstracted). Also, please avoid the _t suffix, which is reserved by POSIX (the broadness and widespread infringement of this reservation are debatable but is nuked anyway if there is not typedef to begin with ;). There is nothing wrong with struct fl_programmer and struct fl_context or struct fl_ctx... or whatever the prefix is. Actually, I deem the former superior to "flashprog" which could mean a number of things e.g. in int fl_flash_probe(fl_flashctx_t **, const fl_flashprog_t *, const char *chip_name); I can come up with at least these meanings: program, programmer, progress. Another side note: > Moving forward is currently more important than finding the perfect name. With that attitude you (plural) are destined to create just another fork(-ish branch). From what I gathered up so far from the gerrit activity this is possible happening already anyway and it might actually be successful (although unintended nand/nor ill-intended and I don't blame you). I will try to give some more feedback soon. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 2

Re: [flashrom] Namespace prefix for libflashrom
by Nico Huber 22 Apr '17

22 Apr '17

On 22.04.2017 20:16, David Hendricks wrote: > Thanks for getting this discussion going on the list, Nico. > > For reference, folks can view the proposed libflashrom.h at > https://review.coreboot.org/#/c/17946 to get a better idea for how these > prefixes will look in libflashrom functions and data structures. > > Also, let's add "fi_" for flashrom interface to the list of proposed > prefixes. > > My preferences (in order): > 1. lf_ > 2. flashrom_ > 3. fi_ > 4. fl_ > 5. flash_ > 6. fr_ > > IMO not only is "lf_" most intuitive, but the way the keys are spaced apart > comfortably on qwerty, dvorak, and colemak layouts and each character > (including the underscore) use a different hand to type. Same could be said > about fl_ with regards to keyboard layout. fr_ is awkward (keys vertically > adjacent) on qwerty and colemak, and fi_ is vertically adjacent on dvorak. > flash_ and flashrom_ are not bad but are obviously many more keystrokes. > > The problem I have with fl_ is that it is also used for flash layout > structs: https://review.coreboot.org/#/c/17944/4/layout.h . The layout > structs are used internally and can be changed easily, though. My bad. Only the `struct fl_layout` is part of the libflashrom inter- face. I removed all other occurrences of the prefix for now from my patches. > > flash_ is pretty good - For the most part it flows well with functions such > as flash_image_read() and flash_image_write(), but is awkward with some > other stuff like "flash_set_log_callback()". If we're already typing >2 > letters I think we ought to just use flashrom_ as the prefix to be > complete, avoid awkward contexts, and avoid namespace conflicts (users > might want to use flash_ in their code). Agreed. Nico > > > On Sat, Apr 22, 2017 at 9:42 AM, Nico Huber <nico.h(a)gmx.de> wrote: > >> Hi flashrom folks, >> >> working again on implementing the libflashrom interface described here >> [1]. During review [2] the question arose what `fl_` means and if we >> don't want to use something else. The following alternatives were pro- >> posed in the wiki: >> >> * fl_ / FL_ (probably *fl*ashrom) >> * lf_ / LF_ (*l*ib *f*lashrom) >> * lfr_ / LFR_ (*l*ib *f*lash *r*om) >> * rom_ / ROM_ >> >> IIRC, on IRC the following was proposed: >> >> * fr_ / FR_ (*f*lash *r*om) >> >> I don't think it has to be an acronym, so I'd add: >> >> * flash_ / FLASH_ >> * flashrom_ / FLASHROM_ >> >> My personal preference would be either `fr_` or `flash_`. >> >> I think this will be open for discussion only for few days. Moving >> forward is currently more important than finding the perfect name. >> >> Best regards, >> Nico >> >> [1] https://www.flashrom.org/Libflashrom >> [2] https://review.coreboot.org/#/c/17946/ >> >> _______________________________________________ >> flashrom mailing list >> flashrom(a)flashrom.org >> https://mail.coreboot.org/mailman/listinfo/flashrom >> >

1 0

Namespace prefix for libflashrom
by Nico Huber 22 Apr '17

22 Apr '17

Hi flashrom folks, working again on implementing the libflashrom interface described here [1]. During review [2] the question arose what `fl_` means and if we don't want to use something else. The following alternatives were pro- posed in the wiki: * fl_ / FL_ (probably *fl*ashrom) * lf_ / LF_ (*l*ib *f*lashrom) * lfr_ / LFR_ (*l*ib *f*lash *r*om) * rom_ / ROM_ IIRC, on IRC the following was proposed: * fr_ / FR_ (*f*lash *r*om) I don't think it has to be an acronym, so I'd add: * flash_ / FLASH_ * flashrom_ / FLASHROM_ My personal preference would be either `fr_` or `flash_`. I think this will be open for discussion only for few days. Moving forward is currently more important than finding the perfect name. Best regards, Nico [1] https://www.flashrom.org/Libflashrom [2] https://review.coreboot.org/#/c/17946/

2 1

Unknown error
by Андрей Макаровский 19 Apr '17

19 Apr '17

I had an error writing to flash chip sst49lf002a on chipset intel ich5: writing sector at 0xb7410300. What could it be? Best regards, Andrew Makarovsky

2 1

Fwd: Re: [#ZJW-196-68375]: how to setup power options
by Martin 19 Apr '17

19 Apr '17

Hello, I have problem after trying flash QNAP TS-453A [~] # hal_app --se_sys_get_system_info NAS display name = TS-453A NAS CPU_0 Model Name = Intel(R) Celeron(R) CPU N3150 @ 1.60GHz NAS CPU_0 running speed = 1601 MHz === Slot1 Mem Info. Channed Id is 1, Slot Addr is 0x50 === Mem Type: DDR3_SDRAM Module Type: SO_DIMM Ram Size: 2048 MB Speed: 1600 MHz Module Manufacture: Transcend Information ECC Support: No === Slot2 Mem Info. Channed Id is 2, Slot Addr is 0x51 === Mem Type: DDR3_SDRAM Module Type: SO_DIMM Ram Size: 2048 MB Speed: 1600 MHz Module Manufacture: Transcend Information ECC Support: No [~] # dmidecode -s bios-version QX47AR12 [~] # hal_app --get_ec_version QX47EC23[~] # cd /share/Public/Temp [/share/Public/Temp] # chmod +x flashrom [/share/Public/Temp] # ./flashrom -p internal:laptop=this_is_not_a_laptop -w QX47AR50.bin flashrom v0.9.8-unknown on Linux 4.2.8 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Active config mode, unknown reg 0x20 ID: 85. Please send the output of "flashrom -V -p internal" to flashrom(a)flashrom.org with W836xx: your board name: flashrom -V as the subject to help us finish support for your Super I/O. Thanks. ======================================================================== WARNING! You may be running flashrom on an unsupported laptop. We could not detect this for sure because your vendor has not setup the SMBIOS tables correctly. You can enforce execution by adding '-p internal:laptop=this_is_not_a_laptop' to the command line, but please read the following warning if you are not sure. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and http://www.flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Proceeding anyway because user forced us to. Found chipset "Intel Braswell". This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0x0 from 0x2a to 0x09 failed. New value is 0x2a. Warning: SPI Configuration Lockdown activated. OK. Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI) mapped at physical address 0xff800000. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error! spi_block_erase_20 failed during command execution at address 0x300000 Reading current flash chip contents... done. Looking for another erase function. spi_block_erase_52 failed during command execution at address 0x300000 Reading current flash chip contents... done. Looking for another erase function. spi_block_erase_d8 failed during command execution at address 0x300000 Reading current flash chip contents... done. Looking for another erase function. spi_chip_erase_60 failed during command execution Reading current flash chip contents... done. Looking for another erase function. spi_chip_erase_c7 failed during command execution Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Apparently at least some data has changed. Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! [/share/Public/Temp] # what I can do now? Br Martin Gawryš Dne 30.3.2017 v 17:40 QNAP Technical Support napsal(a): > > Dobry den, > > vyvojari potvrdili ze problem byl vyresen v poslednim BIOSu pro tuto > NAS, muzete na nej zkusit updatnout? Prikladam detailni navod - budete > k nemu potrebovat pristup k SSH NASky, tam se dostanete napr. pres > PuTTY ( www.putty.org <http://www.putty.org> ) - port 22, uzivatel admin: > > Please follow below SOP to flash BIOS for TS-X53A. > > Preparation: > > * > > Download package from below link: > > N3150: http://download.qnap.com/Storage/tsd/bios/TS-x53A_QX47AR50.zip > > N3160: http://download.qnap.com/Storage/tsd/bios/TS-x53A_QX47AR25.zip > > * > > Extract the compressed file, please upload below 3 files to shared > folder, “Public” > > N3150: flashrom, QX47AR50.bin and QX47EC20.BIN > > N3160: flashrom, QX47AR25 and QX47EC20.BIN > > * > > Follow below commands to complete the BIOS flash procedure. > > 1. Check current CPU name > > There are two version of BIOS, QX47AR50.bin andQX47AR25.bin, > corresponding to N3150and N3160respectively. > > N3150->QX47AR50.bin > > N3160 -> QX47AR25.bin > > CAUTION: Do NOT apply wrong version of BIOS, it will brick your machine. > > [~] # hal_app --se_sys_get_system_info > > NAS display name = TS-453A > > NAS CPU_0 Model Name = Intel(R) Celeron(R) CPU N3150 @ 1.60GHz > > NAS CPU_0 running speed = 1601 MHz > > === Slot1 Mem Info. Channed Id is 1, Slot Addr is 0x50 === > > Mem Type: DDR3_SDRAM > > Module Type: SO_DIMM > > Ram Size: 2048 MB > > Speed: 1600 MHz > > Module Manufacture: Transcend Information > > === Slot2 Mem Info. Channed Id is 2, Slot Addr is 0x51 === > > Mem Type: DDR3_SDRAM > > Module Type: SO_DIMM > > Ram Size: 2048 MB > > Speed: 1600 MHz > > Module Manufacture: Transcend Information > > > > > > > > 2. Check current BIOS and EC version > > CAUTION: User mustdowngrade EC firmware if EC version is higher than > QX47EC20 > > [~] # dmidecode -s bios-version > > QX47AD20 > > [~] # hal_app --get_ec_version > > QX47EC22 > > > > 3. Update BIOS > > For different CPU, user should give different parameter to flashrom. > > N3150: ./flashrom -p internal:laptop=this_is_not_a_laptop -w QX47AR50.bin > > N3160: ./flashrom -p internal:laptop=this_is_not_a_laptop -w QX47AR25.bin > > CAUTION: Do NOT apply wrong version of BIOS, it will brick your machine. > > [~] # cd /share/Public > > [/share/Public] # chmod +x flashrom > > [/share/Public] # ./flashrom -p internal:laptop=this_is_not_a_laptop > -w QX47AR50.bin > > flashrom v0.9.8-unknown on Linux 3.19.8 (x86_64) > > flashrom is free software, get the source code at http://www.flashrom.org > > > Calibrating delay loop... OK. > > Active config mode, unknown reg 0x20 ID: 85. > > Please send the output of "flashrom -V -p internal" to > > flashrom(a)flashrom.org with W836xx: your board name: flashrom -V > > as the subject to help us finish support for your Super I/O. Thanks. > > ======================================================================== > > WARNING! You may be running flashrom on an unsupported laptop. We could > > not detect this for sure because your vendor has not setup the SMBIOS > > tables correctly. You can enforce execution by adding > > '-p internal:laptop=this_is_not_a_laptop' to the command line, but > > please read the following warning if you are not sure. > > > Laptops, notebooks and netbooks are difficult to support and we > > recommend to use the vendor flashing utility. The embedded controller > > (EC) in these machines often interacts badly with flashing. > > See the manpage and http://www.flashrom.org/Laptops for details. > > > If flash is shared with the EC, erase is guaranteed to brick your laptop > > and write may brick your laptop. > > Read and probe may irritate your EC and cause fan failure, backlight > > failure and sudden poweroff. > > You have been warned. > > ======================================================================== > > Proceeding anyway because user forced us to. > > Found chipset "Intel Braswell". > > This chipset is marked as untested. If you are using an up-to-date version > > of flashrom *and* were (not) able to successfully update your firmware > with it, > > then please email a report to flashrom(a)flashrom.org > <mailto:flashrom@flashrom.org> including a verbose (-V) log. > > Thank you! > > Enabling flash write... OK. > > Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI) mapped at > physical address 0xff800000. > > === > > This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE > > The test status of this chip may have been updated in the latest > development > > version of flashrom. If you are running the latest development version, > > please email a report to flashrom(a)flashrom.org > <mailto:flashrom@flashrom.org> if any of the above operations > > work correctly for you with this flash chip. Please include the > flashrom log > > file for all operations you tested (see the man page for details), and > mention > > which mainboard or programmer you tested in the subject line. > > Thanks for your help! > > Reading old flash chip contents... done. > > Erasing and writing flash chip... Erase/write done. > > Verifying flash... VERIFIED. > > 4. Update EC firmware > > CAUTION: User mustdowngrade EC firmware if EC version higher than QX47EC20 > > [/share/Public] # hal_app --update_ec_fw file=QX47EC20.BIN > > > > 5. Reboot NAS with below command. > > [/share/Public] # hal_app --reset_ec_fw > > 6. After the reboot, check BIOS/EC version again > > [~] # dmidecode -s bios-version > > QX47AR50 > > > [~] # hal_app --get_ec_version > > QX47EC20 > > 7. Done. > > > > Best regards, > Lukas Zemina > --------------------------- > Disclaimer: > > Our advice is strictly limited to the question(s) asked and is based > on the information provided to us. QNAP Systems Inc. does not assume > any responsibility or liability for the advice given and shall not be > liable for any direct, indirect, special, incidental or consequential > damages in connection with the use of this information. Any promise, > action or solution we make for your questions does not constitute an > agreement between you and QNAP unless a written agreement signed by > authorized representative is provided. Please always back up your > data. For more information, including technical information updates, > please visit our website at http://www.qnap.com/ > > Ticket Details > ------------------------------------------------------------------------ > Ticket ID: ZJW-196-68375 > Department: Europe - Central & Eastern Europe, Greece, Russia > > Helpdesk: https://helpdesk.qnap.com/index.php?

2 1

Re: [flashrom] Larger SPI NOR flash parts
by David Hendricks 18 Apr '17

18 Apr '17

Hi Alex, Getting 4-byte address support in is something I'm interested in as well. In fact I have parts coming in the mail this week :-) On Mon, Apr 17, 2017 at 6:43 PM, Alex Henderson < ahenderson(a)aparnasystems.com> wrote: > Hi there: > > I just started experimenting with flashrom using a Dediprog > SF600 this weekend. I noticed that there’s no support for any of the 256Mb > or 512Mb SPI NOR parts (4 byte addressing an issue?). > The Dediprog SF600 has commands for 4-byte addressing, but I was not able to get them working in the time I had to play with it. We can probably also ask Dediprog if they have an updated command spec, maybe there was a problem in the one I was looking at. > Is there a newer version than 0.9.9 that I should try? I did find that the > Google fork for chromeOS has a number of these parts (W25Q256, N25Q256, > SST_25F256). > Yes, but the systems those went in treated them as 16MB parts. The firmware (coreboot) is small so there wasn't really need for the extra space. I would be happy to try an unreleased version & report > results. I can also test with an FTDI232 based programmer. The boards I can > test with currently have various versions of 25q512, 25q256, 25q128 and > 25q32. Functionality with the smaller parts looks good. > Great! We've got some pending patches for you to try, then... For the chromiumos branch, try this patch series: https://chromium-review.googlesource.com/c/323359/ (Click "Download" and then you can just checkout the full thing). For upstream, try this: https://mail.coreboot.org/pipe rmail/flashrom/2016-April/014579.html The thing to keep in mind is that there are at least three ways in which 4-byte addressing is handled, and the method depends on the chip: - The chip uses the same instructions for 3-byte and 4-byte operations, but has a status/control register bit that extends the address to 4-bytes. ("Mode 1" in my patch) - The chip has separate instructions for operations using 3-byte and 4-byte addresses. ("Mode 2" in my patch) - The chip only supports 4-byte instructions; 3-byte instructions are not even implemented (The style that Tim's patch addressed) For chromiumos: 1. Clone the flashrom repo: https://chromium.googles ource.com/chromiumos/third_party/flashrom/ 2. cd to the newly created directory (e.g. cd flashrom/) 3. Checkout the patch series: a. Go to https://chromium-review.googlesource.com/c/323359 b. Click "Download" c. Copy these the "Checkout" command and paste it into your terminal.

1 0

Larger SPI NOR flash parts
by Alex Henderson 18 Apr '17

18 Apr '17

Hi there: I just started experimenting with flashrom using a Dediprog SF600 this weekend. I noticed that there's no support for any of the 256Mb or 512Mb SPI NOR parts (4 byte addressing an issue?). Is there a newer version than 0.9.9 that I should try? I did find that the Google fork for chromeOS has a number of these parts (W25Q256, N25Q256, SST_25F256). I would be happy to try an unreleased version & report results. I can also test with an FTDI232 based programmer. The boards I can test with currently have various versions of 25q512, 25q256, 25q128 and 25q32. Functionality with the smaller parts looks good. Alex

1 0

DiskOnChip 2000 Support In Flashrom
by Sundus Hamid 17 Apr '17

17 Apr '17

Hi I have DiskOnChip 2000 flash IC and I wanna read it with my realtek 8139C network card using flashrom. But when I Plugged it in the network card and ran the flashrom I got the following verbose. It didn't checked for DiskOnChip. Kindly help me to read the DiskOnChip IC using falashrom. VERBOSE:root@AK-ED6-063-ubuntu:/usr/sbin# ./flashrom --programmer nicrealtek --verbose flashrom v0.9.5.2-r1517 on Linux 3.19.0 (x86_64), built with libpci 3.1.8, GCC 4.6.3, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 3258M loops per second, delay more than 10% too short (got 82% of expected delay), recalculating... 3276M loops per second, delay more than 10% too short (got 82% of expected delay), recalculating... 3355M loops per second, delay more than 10% too short (got 84% of expected delay), recalculating... 3253M loops per second, delay more than 10% too short (got 82% of expected delay), recalculating... 3282M loops per second, delay loop is unreliable, trying to continue 10 myus = 8 us, 100 myus = 82 us, 1000 myus = 822 us, 10000 myus = 10227 us, 4 myus = 4 us, OK. Initializing nicrealtek programmer Found "Realtek RTL8139/8139C/8139C+" (10ec:8139, BDF 04:00.0). Requested BAR is I/O The following protocols are supported: Parallel. Probing for AMD Am29F010A/B, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BB, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BT, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F016D, 2048 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F040B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080B, 1024 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BB, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BT, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BB, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BT, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BB, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BT, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BB, 1024 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BT, 1024 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV040B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV081B, 1024 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29040B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C512, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C010A, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C040A, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49BV512, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F002(N), 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F002(N)T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Catalyst CAT28F512, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Bright BM29F040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for EMST F49B002UA, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F010, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004BC, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004TC, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400BC, 512 kB: probe_m29f400bt: id1 0x55, id2 0x10 Probing for Fujitsu MBM29F400TC, 512 kB: probe_m29f400bt: id1 0x55, id2 0x10 Probing for Hyundai HY29F002T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Hyundai HY29F002B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Hyundai HY29F040A, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BN/BX-B, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BN/BX-T, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F002BC/BL/BV/BX-T, 256 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F008S3/S5/SC, 512 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-B, 512 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-T, 512 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-B, 512 kB: probe_82802ab: id1 0x55, id2 0x10, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-T, 512 kB: probe_82802ab: id1 0x55, id2 0x10, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F001B, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F001T, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29LV040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000B, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000T, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51400B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51400T, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51000, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51001, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51002, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm29F002T, 256 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm29F002B, 256 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV010, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LH28F008BJT-BTLZ1, 1024 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST28SF040A, 512 kB: probe_82802ab: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE010, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST29LE010, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE020A, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST29LE020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF512, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF010A, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF020A, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF512, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF010, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF080, 1024 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002T/NT, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F040B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BB, 512 kB: probe_m29f400bt: id1 0x55, id2 0x10 Probing for ST M29F400BT, 512 kB: probe_m29f400bt: id1 0x55, id2 0x10 Probing for ST M29W010B, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W040B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W512B, 64 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51001B, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51001T, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51002B, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51002T, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51004B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51004T, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {S,V}29C31004B, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {S,V}29C31004T, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RB, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RT, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012-old, 128 kB: Old Winbond W29* probe method disabled because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29C010(M)/W29C011A/W29EE011/W29EE012-old' if you have a board with such a chip. Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012, 128 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C020(C)/W29C022, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C040/P, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39L040, 512 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49F002U/N, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49F020, 256 kB: probe_jedec_common: id1 0x55, id2 0xaa, id1 parity violation, id1 is normal flash content, id2 is normal flash content No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.

2 1

W836xx: 1657: flashrom -V
by Lakshman Siddartha Yarlagadda 16 Apr '17

16 Apr '17

flashrom v0.9.7-r1852 on Linux 4.2.0-42-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.1, GCC 4.9.1, little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 2681M loops per second, 10 myus = 11 us, 100 myus = 104 us, 1000 myus = 1042 us, 10000 myus = 10170 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Notebook" Laptop detected via DMI. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "HP Pavilion dv6 Notebook PC" DMI string system-version: "058A110014244610000620100" DMI string baseboard-manufacturer: "Hewlett-Packard" DMI string baseboard-product-name: "1657" DMI string baseboard-version: "10.31" W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: 85. Please send the output of "flashrom -V -p internal" to flashrom(a)flashrom.org with W836xx: your board name: flashrom -V as the subject to help us finish support for your Super I/O. Thanks. Found ITE EC, ID 0x8518, Rev 0x02 on port 0x4e.

1 0

Re: [flashrom] Can flashrom be used safely with external USB WCH CH341A & laptop?
by Boyce Humphries 12 Apr '17

12 Apr '17

-------------------------------------------- >On Tue, 4/11/17, Stefan Tauner <stefan.tauner(a)gmx.at> wrote: > > Subject: Re: [flashrom] Can flashrom be used safely with external USB WCH CH341A & laptop? > To: flashrom(a)flashrom.org > Cc: "Boyce Humphries" <boycehumphries(a)yahoo.com> > Date: Tuesday, April 11, 2017, 1:40 PM > > On Tue, 11 Apr 2017 16:22:10 > +0000 (UTC) > Boyce Humphries via flashrom <flashrom(a)flashrom.org> > wrote: > > > hello > @flashrom > > > > Is > there a way to make flashrom NOT LOOK INTERNALLY but > look at the external usb ports for the WCH CH341A > programmer? > > I only have a > laptop. > > Hi, > > flashrom can safely be used > while the laptop is turned off. For a > meaningful way of recovery you will need a > *second* computer to run > flashrom anyway. > There are also some pitfalls: > https://www.flashrom.org/ISP > -- > Kind regards/Mit > freundlichen Grüßen, Stefan Tauner hello again @flashrom Could a flashrom option be added to allow only USB ports to be probed, programmed, etc. External programmers are cheap and there many laptops out here. thanks again Boyce

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom