- flashrom - mail.coreboot.org

Re: [coreboot] Re: [LinuxBoot] FOSDEM 2019 deadline today
by Carl-Daniel Hailfinger 01 Feb '19

01 Feb '19

On 01.02.2019 08:48, Martin Kepplinger wrote: > On 24.01.19 01:05, Carl-Daniel Hailfinger wrote: >> Hey everyone, >> >> just 9 days until FOSDEM in Brussels (2+3 February)! >> There are a couple of talks about coreboot and LinuxBoot and we have a >> coreboot/LinuxBoot/flashrom stand (building AW). Plus, there is a >> hardware enablement devroom. >> >> - Who's coming? >> - Are you volunteering for a shift at the stand? >> - What demo hardware can you bring? (We have only 1 table, so smaller >> hardware is preferred.) >> - What merchandise/giveaways can you bring? >> - Do we have 1-page flyers about each of coreboot, LinuxBoot and >> flashrom? (PDF is sufficient, I can print in black+white if needed.) >> - Do we have a large coreboot/LinuxBoot/flashrom banner which helps >> others find our stand? >> > hi, > > how're you doing with organisation? It's a bit chaotic, but I think we can manage. > I'm doing a 10min lightning talk about my little x230 coreboot project > tomorrow and obviously have that with me. > > There are talks I'll definitely attend, but in case you urgently need > somebody at the stand for a short shift, please just ask. > > I only have my X230 and some flashing hardware with me. It would be nice if you could stop by at our booth. We don't have a plan yet for the shifts at the booth, but I hope we can get something organized either tonight or tomorrow in the morning. Thanks, Carl-Daniel

1 0

flashrom, and 4-byte addressing SPI (example: MX25L25635E)
by Евгений 29 Jan '19

29 Jan '19

Good day. MacOS+Homebrew+flashrom. Flashrom does not understand 4 byte addressing (chips > 16MB). With 3 byte addressing work perfectly (chips <= 16MB). May you add 4 byte addressing for SPI flash? Example MX25L25635E - 32MB uses in different new routers. CH341 in Windows work with 4 byte and read/write flash and registers from this SPI flash: JEDEC ID(9F) = 0xC22019 RES ID(AB) = 0x001818 REMS ID(90) = 0x00C218 Sreg: 00000000(0x00), 11111111(0xFF), 00000111(0x07) but on MacOS not software that can do it.

2 1

flash chips not supported - modify config file?
by Hugo.Bitard 28 Jan '19

28 Jan '19

Hello, First of all, i would tell you that you do an amazing work with flashrom. It is really awsome!! I would like to dump the firmware of an Atmel 24C01A, but this flash chips is not a supported one. I found 2 files, that could be of interest: flashchips.c and flashchips.h, but i do not know how to modify it in order to support the Atmel 24C01A chips. If you could give me some advice about the procedure, it could be very helpful. Thank in advance Best regards Hugo message envoyé depuis ProtonMail

1 0

Re: [flashrom] [coreboot] [LinuxBoot] FOSDEM 2019 deadline today
by Carl-Daniel Hailfinger 26 Jan '19

26 Jan '19

In that case, I'd also like to point you to the deadline for submitting main track talks which is tomorrow(!). https://fosdem.org/2019/news/2018-08-10-call-for-participation/ Having a coreboot/LinuxBoot talk there would be awesome. Ron/David, could you submit something or do you have someone in mind who can do that? There's also lightning talks, deadline is a bit later. OK, I'm submitting a request for a stand. I need a backup contact for the stand. Who is willing to do that? AFAICS we can still change the backup contact later if life happens. Regards, Carl-Daniel On 02.11.2018 20:48, David Hendricks wrote: > > > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot > <linuxboot(a)googlegroups.com <mailto:linuxboot@googlegroups.com>> wrote: > > I"m leaning to yes, by which I mean if you do it, I'll show up. > > I can't believe I said that. > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net > <mailto:c-d.hailfinger.devel.2006@gmx.net>> wrote: > > > > Hi! > > > > FOSDEM next year will be on 2 & 3 February 2019. > > The deadline for applying for a stand is today. > > Do we want a coreboot/flashrom/LinuxBoot stand/booth? > > > Same as what Ron said. I think someone from FB can be there to talk > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo. > >

5 8

Google Coral ChromeBook issue
by Bank Wu 25 Jan '19

25 Jan '19

Hi There, I have an issue that cannot disable write protection mode on a dell chomebook which FW is Google_Coral_10068.63.0. Both BIOS and EC flash ROM were reprogrammed with brand new chips before we installed the RMA shim R69. 1. flashrom -p host -wp-disable (AC only, Battery is disconnected) coreboot table found at 0x7ab36000. FAILED [cid:image002.png@01D4B497.AC197D40] 2. fmap_decode readbios.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="35" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x0017b000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00380000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="RO_UNUSED" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00200000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags="" 3. flashrom -p host -w bios.bin Calibrating delay loop... OK. coreboot table found at 0x7ab36000. Erasing and writing flash chip... Good. It seems nothing was changed. FAILED [cid:image003.png@01D4B497.AC197D40] Yuehui(Bank) Wu Testing Engineer MLB Engineering CSAT Solutions LP Work: +1 (713) 934-5200 Mobile: +1 (832) 729-1686 www.csat-solutions.com<http://www.csat-solutions.com/> Bank.Wu(a)csat-solutions.com<mailto:bank.wu@csat-solutions.com> [cid:image001.png@01D16F22.E9FCB900]

1 0

flashrom v1.0 on Linux 4.20.3-gentoo (x86_64) with ch341a and GigaDevice GD25Q40(B)
by Néstor A. Marchesini 23 Jan '19

23 Jan '19

-------------------------------------------------------------------------------- Read 1 original memory. $ time flashrom --programmer ch341a_spi --chip "GD25Q40(B)" --read SAMSUNG-LS23C350H-00-original-GD25Q40B.bin -V flashrom v1.0 on Linux 4.20.3-gentoo (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.6.2, GCC 8.2.0, little endian Command line (7 args): flashrom --programmer ch341a_spi --chip GD25Q40(B) --read SAMSUNG-LS23C350H-00-original-GD25Q40B.bin -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing ch341a_spi programmer Device revision is 3.0.4 The following protocols are supported: SPI. Probing for GigaDevice GD25Q40(B), 512 kB: probe_spi_rdid_generic: id1 0xc8, id2 0x4013 Found GigaDevice flash chip "GD25Q40(B)" (512 kB, SPI) on ch341a_spi. Chip status register is 0x00. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set Chip status register: Block Protect 4 (BP4) is not set Chip status register: Block Protect 3 (BP3) is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set === 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 flash... done. real 0m4,524s user 0m0,191s sys 0m0,006s -------------------------------------------------------------------------------- Read 2 original memory. $ time flashrom --programmer ch341a_spi --chip "GD25Q40(B)" --read SAMSUNG-LS23C350H-01-original-GD25Q40B.bin -V flashrom v1.0 on Linux 4.20.3-gentoo (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.6.2, GCC 8.2.0, little endian Command line (7 args): flashrom --programmer ch341a_spi --chip GD25Q40(B) --read SAMSUNG-LS23C350H-01-original-GD25Q40B.bin -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing ch341a_spi programmer Device revision is 3.0.4 The following protocols are supported: SPI. Probing for GigaDevice GD25Q40(B), 512 kB: probe_spi_rdid_generic: id1 0xc8, id2 0x4013 Found GigaDevice flash chip "GD25Q40(B)" (512 kB, SPI) on ch341a_spi. Chip status register is 0x00. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set Chip status register: Block Protect 4 (BP4) is not set Chip status register: Block Protect 3 (BP3) is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set === 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 flash... done. real 0m4,542s user 0m0,187s sys 0m0,006s -------------------------------------------------------------------------------- List and compare the two reads. $ ls -l SAMSUNG-LS23C350H-0?-original-GD25Q40B.bin -rw-r--r-- 1 nestor nestor 524288 ene 23 03:38 SAMSUNG-LS23C350H-00-original-GD25Q40B.bin -rw-r--r-- 1 nestor nestor 524288 ene 23 03:40 SAMSUNG-LS23C350H-01-original-GD25Q40B.bin $ ls -lh SAMSUNG-LS23C350H-0?-original-GD25Q40B.bin -rw-r--r-- 1 nestor nestor 512K ene 23 03:38 SAMSUNG-LS23C350H-00-original-GD25Q40B.bin -rw-r--r-- 1 nestor nestor 512K ene 23 03:40 SAMSUNG-LS23C350H-01-original-GD25Q40B.bin $ cmp SAMSUNG-LS23C350H-00-original-GD25Q40B.bin SAMSUNG-LS23C350H-01-original-GD25Q40B.bin -b All ok, the compare are equals. $ eix -I flashrom [I] sys-apps/flashrom Available versions: 0.9.6.1 0.9.7 0.9.8 (~)0.9.9 (~)1.0 **9999 {atahpt +atapromise +atavia +bitbang_spi +buspirate_spi +ch341a_spi (+)dediprog +developerbox_spi +digilent_spi doc +drkaiser +dummy (+)ft2232_spi +gfxnvidia +internal +internal_dmi +it8212 +linux_mtd +linux_spi mstarddc_spi +nic3com +nicintel +nicintel_eeprom +nicintel_spi nicnatsemi (+)nicrealtek +ogp_spi +pickit2_spi +pony_spi (+)rayer_spi (+)satamv +satasii +serprog static tools usbblaster +usbblaster_spi +wiki} Installed versions: 1.0(03:41:50 07/11/18)(buspirate_spi ch341a_spi dummy ft2232_spi internal internal_dmi linux_spi pickit2_spi pony_spi serprog tools wiki -atahpt -atapromise -atavia -dediprog -drkaiser -gfxnvidia -it8212 -mstarddc_spi -nic3com -nicintel -nicintel_eeprom -nicintel_spi -nicnatsemi -nicrealtek -ogp_spi -rayer_spi -satamv -satasii -static -usbblaster_spi) Homepage: https://flashrom.org/ Description: Utility for reading, writing, erasing and verifying flash ROM chips I'am gentoo testing branck ~amd64 and I have ch341a and buspirate 3.5c, my motherboard is Gigabyte GA-990FXA-UD7 r1.00 with AMD FX8350 processor. Regards and thaks for make flashrom great!

1 0

ENE KB9012QF A3 reflash help needed
by Nyúlós Lónyál 20 Jan '19

20 Jan '19

Hi! I'm trying to flash an ENE KB9012QF A3 KBC on LA-8241P motherboard. The problem is flashrom can't detect the internal SPI of it, fails with error. flashrom p1.0-141-g9cecc7e on Linux 4.15.0-20-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.5.2, GCC 7.3.0, little endian Command line (5 args): ./flashrom -p rayer_spi -c KB9012 (EDI) -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing rayer_spi programmer Using address 0x378 as I/O base for parallel port access. Using RayeR SPIPGM pinout. The following protocols are supported: SPI. Probing for ENE KB9012 (EDI), 128 kB: edi_chip_probe: reading hwversion failed No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. How to get it working? Thanks a lot for help!

4 19

Found chipset "VIA VT82C597" with PCI ID 1106:0597. Works
by William Smart 18 Jan '19

18 Jan '19

Greetings Flashrom Crew! Found chipset "VIA VT82C597" with PCI ID 1106:0597. I was able to flash a bios on this chipset, using an EPOX EP-MVM3G2 mainboard, verbose log attached. Thanks!!! Bill

1 0

Thomas-Krenn-Award 2019 - Win server hardware for Open Source Projects
by Thomas Niedermeier 18 Jan '19

18 Jan '19

Dear Ladies and Gentlemen, I hope you had a good start into the new year. Since you have already successfully applied for the Thomas-Krenn-Award with your project Flashrom, I would like to draw your attention to this year's award. Open source projects can again win server hardware with a total value of 6,500 Euros. The submission of a project is very easy - you select three configurations (1500 €, 2000 € and 3000 € net value of goods) and send an e-mail to award(a)thomas-krenn.com with a description for what purpose the server would be used in the project. All details can be found below: https://www.thomas-krenn.com/en/companies/about-us/thomas-krenn-award.html We at Thomas-Krenn would be delighted if you and your project could participate in our award again. You can also forward the information to other developers in the open source community (one submission per project is possible. There is also no registered association required to submit the project.) The registration deadline is 27.01.2019. Best regards, Thomas Niedermeier Thomas Niedermeier Knowledge Transfer E-Mail: tniedermeier(a)thomas-krenn.com Tel: +49 8551 91 50 264 [Lassen Sie sich zu Windows Server 2019 beraten]<https://www.thomas-krenn.com/de/produkte/software/microsoft-software/window…> Thomas-Krenn.AG; Speltenbach-Steinäcker 1; 94078 Freyung; Sitz der Gesellschaft: Freyung | HRB 6790; Vorstand: Ralf Hohmann, Christoph Maier; AR-Vorsitzender: Guido Bollue [Xing]<https://www.xing.com/companies/thomas-krenn.ag> [Facebook] <https://www.facebook.com/thomaskrenn.ag> [Twitter] <https://twitter.com/thomaskrennag> [LinkedIn] <https://de.linkedin.com/company/thomas-krenn.ag>

1 0

AsRock Z370 Extreme4 not supported
by flashrom＠prvy.eu 18 Jan '19

18 Jan '19

1 0

patch for allowing the use of the SOCKET target of the SF600
by Florian Kaiser 15 Jan '19

15 Jan '19

Hello, I am using this patch for a while now and I did not encounter any problems. I am not sure if this was/is not supported. Is there any reason why this is not supported? Thank you very much, Florian Kaiser

4 3

patch: add support for the MCP2210
by Máté Kukri 12 Jan '19

12 Jan '19

Hello, This patch adds support for the MCP2210 USB to SPI bridge as a programmer. Since the MCP2210 is an HID device I have a working version using both libusb and hidraw + udev for finding the device. I have already made a github pull request with more details: https://github.com/flashrom/flashrom/pull/68. But I am posting it here as well. Máté Kukri

1 0

Atmel AT49F002(N)T erase and write (was:asus p2b - successful erase and write)
by Branden Waldner 12 Jan '19

12 Jan '19

I realized I mixed up the flash part status with the motherboard, so figured I'd better make that clear. Sorry about that. On 1/4/19, Branden Waldner <scruffy99(a)gmail.com> wrote: > I got an asus p2b to go with my asus p2-99 for coreboot testing and it > works with flashrom. > > Erase and write are reported as untested, so attached are logs of > flashing from the award bios and from coreboot. It reports failure > when trying erase function 0, but tries erase function 1 and works. It > also requires the this_is_not_a_laptop option to work with the award > bios. > > I can do any further testing or supply logs if required. >

1 0

Is it possible to change only DMI data using flashrom ?
by Марк Коренберг 08 Jan '19

08 Jan '19

I want to change, say, serial number of motherboard. -- Segmentation fault

2 1

Help with a Winbond W25Q16
by iafdan 08 Jan '19

08 Jan '19

Hi to the cool guys from Flashrom! I'm trying to dump the contents of a Winbond W25Q16 using the command: ./flashrom -p ft2232_spi:type=232H,port=A -c W25Q16 -r dump.rom I'm getting an error that: This flash part has status NOT WORKING for operations... However, when I do "flashrom -L" the W25Q16 chip, with the exact same ID appears on the list. Here's a verbose output: https://paste.flashrom.org/view.php?id=3163 I also tried reading the chip without specifying the exact chip. Many thanks!!

2 1

asus p2b - successful erase and write
by Branden Waldner 05 Jan '19

05 Jan '19

I got an asus p2b to go with my asus p2-99 for coreboot testing and it works with flashrom. Erase and write are reported as untested, so attached are logs of flashing from the award bios and from coreboot. It reports failure when trying erase function 0, but tries erase function 1 and works. It also requires the this_is_not_a_laptop option to work with the award bios. I can do any further testing or supply logs if required.

1 0

new hardware
by Kajus Kevevari 03 Jan '19

03 Jan '19

Hello, I noticed that "winbond" flash W25Q256.V is marked as UNTESTED. I tested read and write functions and they work correct. I was able to fire up board after re flashing with Amontech JTAGkey2 programmer. Attaching some prove. Good day! [image: image.png] [image: image.png] [image: image.png]

1 0

Flashrom for DOS?
by Woockash O 02 Jan '19

02 Jan '19

Hi, I am trying to flash my BIOS chip in Wyse SX30 thin client with Coreboot image. According to various articles, flashrom should be able to do that. However SX30 doesn't like most linux distributions (due to problems with BIOS that should be fixed after flashing the chip). I would like to try flashing it with flashrom release for DOS (freedos seems to work with no issues). However for some reason I am not able to access your buildbot website (tried on several browsers and networks). I have found only an old release (0.9.4) on another website. If there are any issues with buildbot site, could you please point me to the location where I can get some newer releases for DOS (at least 0.9.8)? Thanks Luc

1 0

Re: [flashrom] Cleanup patches for flashrom
by Nico Huber 02 Jan '19

02 Jan '19

Hi Richard, On 20.12.18 11:11, Richard Hughes wrote: > We're slowly moving towards using libflashrom in fwupd, rather than > exec'ing the flashrom binary and screen scraping. So that it can be > consumed by users easily, I'm tempted to use flashrom as a subproject > to the fwupd project rather than waiting for distros to ship any new > bleeding edge version of flashrom to users. To make some of that > possible, I've fixed up a few of the CI failures we would see in > fwupd, which I've filed as a PR here: > https://github.com/flashrom/flashrom/pull/67 thanks. > > If a GitHub PR isn't how you want these kind of general patches please > let me know. One person already told me that I needed to use Gerrit, When we switched to Gerrit, we decided to still allow patches per email and also on GitHub. Though, all patches have to go through Gerrit in the end as that's where the official repository is. I've never been active on GitHub (my account is only few months old). And the developers that set the flashrom mirror up there obviously had the best intentions (pull requests are mentioned in the project des- cription) but aren't actively reviewing atm. I also can't say anymore that everything on Gerrit gets a review, though smaller changes do. If you'd use Gerrit, you'd hit the remaining active reviewers right in their everyday workflow. > but I'm not overly keen on learning a new process if I can avoid it. > Feedback welcome, thanks. I just tried, it was horrible ;) I just can't find a way to comment on individual commits of your PR (beside commenting inline in the code). I'll leave some comments their and pull those commits that seem ready to go. Nico

2 1

Hardware support
by Waltteri Koskinen 02 Jan '19

02 Jan '19

Hello! I wanted to report that I have successfully probed, read, erased and wrote in this chip https://www.mouser.fi/datasheet/2/308/LE25U40CMD-D-972803.pdf I used raspberry pi 1.gen and linux_spi. Thank you for this fantastic software it saved my pc display. BR. Waltteri Koskinen

1 0

FAILED: Asus Chromebox 3 / CN65 (TEEMO)
by Markku Viholainen 02 Jan '19

02 Jan '19

Hi, do you have any idea what to do with folowing error? ChromeOS Firmware Utility Script [2018-12-30] (c) Mr Chromebox <mrchromebox(a)gmail.com> ********************************************************* ** Device: Asus Chromebox 3 / CN65 (TEEMO) ** CPU Type: Intel KabyLake ** Fw Type: Stock ChromeOS ** Fw WP: Disabled ********************************************************* ** 1) Install/Update RW_LEGACY Firmware ** 2) Install/Update BOOT_STUB Firmware ** [WP] 3) Install/Update Full ROM Firmware ** [WP] 4) Set Boot Options (GBB flags) ** [WP] 5) Set Hardware ID (HWID) ** 6) Remove ChromeOS Bitmaps ** 7) Restore ChromeOS Bitmaps ** 8) Restore Stock BOOT_STUB ** 9) Restore Stock Firmware (full) ********************************************************* Select a menu option or R to reboot P to poweroff Q to quit 3 Install/Update UEFI Full ROM Firmware Standard disclaimer: flashing the firmware has the potential to brick your device, requiring relatively inexpensive hardware and some technical knowledge to recover. You have been warned. Also, flashing Full ROM firmware will remove your ability to run ChromeOS. Do you wish to continue? [y/N] y NOTE: After flashing UEFI firmware, you will need to install a UEFI-compatible OS; ChromeOS will no longer be bootable. UEFI firmware supports Windows and Linux on all devices. Debian/Ubuntu-based distros require a small fix to boot after install -- see https://mrchromebox.tech/#faq for more info. Press Y to continue or any other key to abort. y Create a backup copy of your stock firmware? This is highly recommended in case you wish to return your device to stock configuration/run ChromeOS, or in the (unlikely) event that things go south and you need to recover using an external EEPROM programmer. [Y/n] n Downloading Full ROM firmware (coreboot_tiano-fizz-mrchromebox_20181230.rom) Disabling software write-protect and clearing the WP range Installing Full ROM firmware (may take up to 90s) flashrom v0.9.9 : 266087c : Nov 20 2018 01:07:48 UTC on Linux 4.4.159-15346-gc5e629939ae0 (x86_64) Calibrating delay loop... OK. coreboot table found at 0x7aac2000. WARNING: SPI Configuration Lockdown activated. Erasing and writing flash chip... Verifying flash... VERIFY FAILED at 0x00000086! Expected=0x40, Read=0xc0, failed byte count from 0x00000000-0x00ffffff: 0x2 Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with FAILED: your board name in the subject line! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! FAILED An error occurred flashing the Full ROM firmware. DO NOT REBOOT! Press [Enter] to return to the main menu.^C +Markku+

1 0

Flashing Asus KGPE-D16 Chip
by Joshua Aspinall 02 Jan '19

02 Jan '19

Hi, I am attempting to write a Libreboot ROM to my BIOS chip. The chip reports as follows: sudo flashrom -p linux_spi:dev=/dev/spidev0.0 'Found Winbond flash chip "W25Q16.V" (2048 kB, SPI) on linux_spi.' All of the online guides show reading the chip before attempting to flash, and confirming that the checksums match. However, when reading the contents of the flash chip, the checksums vary wildly. When attempting to flash the chip with a Libreboot ROM for the board, the erase function fails on all attempts as follows: sudo flashrom --programmer linux_spi:dev=/dev/spidev0.0 --write kgpe-d16_ukqwerty_txtmode.rom flashrom p1.0-141-g9cecc7e on Linux 4.14.79+ (armv6l) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Using default 2000kHz clock. Use 'spispeed' parameter to override. Found Winbond flash chip "W25Q16.V" (2048 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0x1000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x000007fd! Expected=0xff, Found=0xfe, failed byte count from 0x00000000-0x00007fff: 0x6218 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x000001bb! Expected=0xff, Found=0xfc, failed byte count from 0x00000000-0x0000ffff: 0xbde4 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x001fffff: 0x18a7c0 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000111! Expected=0xff, Found=0xc0, failed byte count from 0x00000000-0x001fffff: 0x18af13 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. 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. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! I am trying to determine whether I am doing something incorrectly, or whether the chip is unserviceable and needs to be replaced. Any help/hints would be greatly appreciated! Best Regards, Joshua Aspinall.

2 1

Re: FAILED MARS
by Ivan Ivanov 31 Dec '18

31 Dec '18

Dear Tom, very happy to see your success :) Although I hope that you are installing Win7 not Win10 aka "spyware edition" ;) Happy New Year ! ;) BR, Ivan пн, 31 дек. 2018 г. в 21:44, Tom Santos <tom.81748418(a)gmail.com>: > > Good news!!! > > i just close and open google chrome and run the script again and done!! > > sorry for bad english, thanks for your support!! > > happy new year!!! > > Em segunda-feira, 31 de dezembro de 2018, Ivan Ivanov <qmastery16(a)gmail.com> escreveu: >> >> You may try to flash this image directly using flashrom, not using >> someone else's scripts because they might be faulty... >> >> пн, 31 дек. 2018 г. в 19:36, Tom Santos <tom.81748418(a)gmail.com>: >> > >> > Help pleas !!!! >> > >> > -- >> > Att, >> > >> > >> > Tom Santos. >> > >> > >> > >> > >> > A mente cria, o desejo atrai e a fé realiza. >> > _______________________________________________ >> > flashrom mailing list -- flashrom(a)flashrom.org >> > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > -- > Att, > > > Tom Santos. > > > > > A mente cria, o desejo atrai e a fé realiza. >

1 0

FAILED MARS
by Tom Santos 31 Dec '18

31 Dec '18

Help pleas !!!! -- Att, Tom Santos. A mente cria, o desejo atrai e a fé realiza.

2 1

Successful flash of ASRock soldered BIOS via BIOS_PH header
by David Bartley 30 Dec '18

30 Dec '18

I have an ASRock Z390M-ITX/ac motherboard with a soldered/non-removable BIOS chip (this is apparently not uncommon on ASRock motherboards). I initially tried using test clips, but I wasn't able to get a good connection. Fortunately, the motherboard features a BIOS_PH header that is wired to the BIOS chip. Despite existing on multiple motherboards, its pinout is seemingly only documented in the J3355M manual ( http://asrock.pc.cdn.bitgravity.com/Manual/J3355M.pdf). Using this pinout, I was able to connect some jumpers from the BIOS_PH header to a CH341A programmer and successfully read from and write to the chip (a W25Q128JVSIQ in my case). For reference, the BIOS_PH pinout (corresponding to a 25xx chip) is: DI | GND CLK | no connection no pin | DO VCC | CS HOLD | WP

1 0

Thinkpad T410s failed to erase (corrupted?)
by Sea Wright 29 Dec '18

29 Dec '18

Hi all, While trying to get coreboot working on a T410s, in the most recent flash (after multiple working successful flashes) the clip detached in the middle of the write process. I saw some error message briefly (I think it mentioned corrupted) before my ssh session terminated before I could finish reading it. Now, with a new clip, I can read the chip perfectly, but trying to write/erase leads to these errors: https://paste.flashrom.org/view.php?id=3156 Failed at 0x0000000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x007fffff: 0x3dc7fe It is possible to write what is read from the chip (eh cock doesn't match what I tried to write to it) back onto it without failure. Any suggestions? menaechmi

2 1

Report of flashrom failure (Intel DQ67OW motherboard)
by Tom Crane 28 Dec '18

28 Dec '18

Dear Flashrom developers, Please find attached my failure report as suggested in flashrom O/P. The PC has been updated with the latest BIOS (file SWQ6710H.86A.0070.BI.zip from Intel) and I am running a built-today git version of flashrom. Thanks Tom Crane

2 1

Testing new mailing list
by Carl-Daniel Hailfinger 25 Dec '18

25 Dec '18

Test

1 0

Re: [flashrom] 80/100/132 column line width policy
by Nico Huber 23 Dec '18

23 Dec '18

On 19.12.18 20:34, David Hendricks wrote: > Regarding exceptions, I was taught that function signatures in header >> files are an exception too. I don't mind either way, but if the rules >> disagree with the current practice, we should make that explicit. >> > > This makes sense, but can linters be taught the difference between source > and header files? It would be nice to enforce the hard limit via commit > hook. I wouldn't mind a commit hook as long as a human has the last word. If linters can be taught? I'm sure they can if they are open-source. Maybe I don't get the question. Nico

1 0

Re: [flashrom] Please Help
by Nico Huber 23 Dec '18

23 Dec '18

Hello Ben, I've been looking at your mail again and what looked like a hardware failure first, obviously isn't: > Some block protection in effect, disabling... Block protection could not be > disabled! (Alas, error messages can somehow be missed in verbose logs...) This is likely caused by a wrong state on a /WP pin. It should be high, deasser- ted. Hope that helps, Nico

1 0

Cleanup patches for flashrom
by Richard Hughes 20 Dec '18

20 Dec '18

Hi all, We're slowly moving towards using libflashrom in fwupd, rather than exec'ing the flashrom binary and screen scraping. So that it can be consumed by users easily, I'm tempted to use flashrom as a subproject to the fwupd project rather than waiting for distros to ship any new bleeding edge version of flashrom to users. To make some of that possible, I've fixed up a few of the CI failures we would see in fwupd, which I've filed as a PR here: https://github.com/flashrom/flashrom/pull/67 If a GitHub PR isn't how you want these kind of general patches please let me know. One person already told me that I needed to use Gerrit, but I'm not overly keen on learning a new process if I can avoid it. Feedback welcome, thanks. Richard

1 0

Re: [flashrom] 80/100/132 column line width policy
by Nico Huber 19 Dec '18

19 Dec '18

Hi, Am 15.12.18 um 02:49 schrieb David Hendricks: > This topic came up in a patch submission, and it occurred to me that we > never actually wrote down canonical limits in the wiki. So I went ahead and > added the proposed limits here: > https://www.flashrom.org/Development_Guidelines#Coding_style thanks, this was bugging me for long, but I didn't know when it was discussed. > > It seems that we never really decided on 112-characters vs. 120-characters, > so I wrote down 112-characters for now. I guess time decided. 112 chars feels more than enough, IMHO. > At least most were satisfied with > an 80-column "soft" limit and an exception to the limits for tables... Regarding exceptions, I was taught that function signatures in header files are an exception too. I don't mind either way, but if the rules disagree with the current practice, we should make that explicit. Actually, I can't recall ever hearing about a soft limit. Though, I like the idea. I tried to formalize something like that once with the notion of a "visible width" during a [coreboot] discussion. Quoting myself here in case somebody is interested: > [...] I see three > major cases that people care about: > > 1. Function signatures, > 2. Code lines and > 3. Code lines containing string literals[1]. > > Let's assume 72 chars of visible width (line length minus the inden- > tation) is enough for code lines. If we say two additional indentation > levels are always reasonable (a third might be too, here and there) we > would be at 96 chars. > > So I would compromise as follows: > > o Set a hard limit around 100 chars (96 would be a nice number). > o If a line doesn't contain a string literal, recommend a > visible width <= 72 chars. > > Nico > > [1] I think we should treat the latter two separately because you can > easily argue that lines with a string literal might get too long but > if you apply the same rules to regular code, you'll get all the > crappy stuff (too many levels of indentation, unnecessary long, less > distinctive identifiers etc.). Full message here[2]. That would only apply to the bulk of the code and comments. For me, carefully hand-formatted passages (like tables) are always an exception. Nico [2] https://mail.coreboot.org/pipermail/coreboot/2018-May/086834.html

2 1

80/100/132 column line width policy
by Carl-Daniel Hailfinger 15 Dec '18

15 Dec '18

Hi, we're hitting the 80 column limit in our code in ways which actually reduce readability for the code. Examples are various multiline messages and complicated nested code where refactoring to a separate function doesn't make sense. Keeping the old 80 column limit is not really an option anymore. Standard terminal sizes have one of 80, 100 or 132 columns. Given the monitor resolutions many people have nowadays, I think it is safe to say that you can fit two xterms with 100 columns horizonally next to each other. 100 columns should also be sufficient for a msg_p* of roughly 80 columns of text. 132 columns provide more leeway, but IMHO that would be too wide for good readability (and my screen can't fit two xterms side-by-side anymore). Of course some files have sections where any column limit is not acceptable (board lists etc.), but the column limit violations should be limited to the affected file sections, not whole files. Comments? I'd like to get this decided today or tomorrow so we know where we need line breaks in Stefan Tauner's new struct flashchip patch. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 9

reporting a failed verify
by Joy 08 Dec '18

08 Dec '18

sudo flashrom --programmer ch341a_spi -w 2ndpad_NVRAM.rom flashrom v0.9.9-rc1-r1942 on Linux 4.4.0-62-lowlatency (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x000a01a1! Expected=0x8c, Found=0x8e, failed byte count from 0x00000000-0x007fffff: 0x7e Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!

1 0

Please Help
by Benjamin Murdock 05 Dec '18

05 Dec '18

I am trying to duplicate the audio stored on a GPR25L040B chip. The datasheet ( https://www.dataman.com/media/datasheet/Generalplus/GPR25L040B.pdf) states that it is fully compatible with the MX25L4005A. I seem to be able to read the flash to a file just fine but when writing back to the file I am getting an error (see below). Even with the error, I seem to be able to at least partially write to the chip but the audio that comes back cuts out after a few seconds. This project's goal is to copy audio from a recorded book that my son's grandma recorded with him before she passed, to another book that we can give to my Sister-In-Law for Christmas. I would also like to back up the audio in case something happens to the book in the future. (Alternate backups will be made as well prior to touching that book.) . Any help that you can provide would be greatly appreciated. Thank you, Ben. The following protocols are supported: SPI. Probing for Macronix MX25L4005(A/C)/MX25L4006E, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2013 Found Macronix flash chip "MX25L4005(A/C)/MX25L4006E" (512 kB, SPI) on linux_spi. Chip status register is 0x86. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set Chip status register: Bit 6 is not set Chip status register: Bit 5 is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is set Chip status register: Write In Progress (WIP/BUSY) is not set Some block protection in effect, disabling... Block protection could not be disabled! Chip status register is 0x86. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set Chip status register: Bit 6 is not set Chip status register: Bit 5 is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is set Chip status register: Write In Progress (WIP/BUSY) is not set Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:S, 0x001000-0x001fff:S, 0x002000-0x002fff:S, 0x003000-0x003fff:S, 0x004000-0x004fff:S, 0x005000-0x005fff:S, 0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S, 0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:S, 0x00c000-0x00cfff:S, 0x00d000-0x00dfff:S, 0x00e000-0x00efff:S, 0x00f000-0x00ffff:S, 0x010000-0x010fff:S, 0x011000-0x011fff:S, 0x012000-0x012fff:S, 0x013000-0x013fff:S, 0x014000-0x014fff:S, 0x015000-0x015fff:S, 0x016000-0x016fff:S, 0x017000-0x017fff:S, 0x018000-0x018fff:S, 0x019000-0x019fff:S, 0x01a000-0x01afff:S, 0x01b000-0x01bfff:S, 0x01c000-0x01cfff:S, 0x01d000-0x01dfff:S, 0x01e000-0x01efff:S, 0x01f000-0x01ffff:S, 0x020000-0x020fff:S, 0x021000-0x021fff:S, 0x022000-0x022fff:S, 0x023000-0x023fff:S, 0x024000-0x024fff:S, 0x025000-0x025fff:S, 0x026000-0x026fff:S, 0x027000-0x027fff:S, 0x028000-0x028fff:S, 0x029000-0x029fff:S, 0x02a000-0x02afff:S, 0x02b000-0x02bfff:S, 0x02c000-0x02cfff:S, 0x02d000-0x02dfff:S, 0x02e000-0x02efff:S, 0x02f000-0x02ffff:S, 0x030000-0x030fff:S, 0x031000-0x031fff:S, 0x032000-0x032fff:S, 0x033000-0x033fff:S, 0x034000-0x034fff:S, 0x035000-0x035fff:S, 0x036000-0x036fff:S, 0x037000-0x037fff:S, 0x038000-0x038fff:S, 0x039000-0x039fff:S, 0x03a000-0x03afff:S, 0x03b000-0x03bfff:S, 0x03c000-0x03cfff:S, 0x03d000-0x03dfff:S, 0x03e000-0x03efff:S, 0x03f000-0x03ffff:S, 0x040000-0x040fff:S, 0x041000-0x041fff:S, 0x042000-0x042fff:S, 0x043000-0x043fff:S, 0x044000-0x044fff:S, 0x045000-0x045fff:S, 0x046000-0x046fff:S, 0x047000-0x047fff:S, 0x048000-0x048fff:S, 0x049000-0x049fff:S, 0x04a000-0x04afff:S, 0x04b000-0x04bfff:S, 0x04c000-0x04cfff:S, 0x04d000-0x04dfff:S, 0x04e000-0x04efff:S, 0x04f000-0x04ffff:S, 0x050000-0x050fff:S, 0x051000-0x051fff:S, 0x052000-0x052fff:S, 0x053000-0x053fff:S, 0x054000-0x054fff:S, 0x055000-0x055fff:S, 0x056000-0x056fff:S, 0x057000-0x057fff:S, 0x058000-0x058fff:S, 0x059000-0x059fff:S, 0x05a000-0x05afff:S, 0x05b000-0x05bfff:S, 0x05c000-0x05cfff:S, 0x05d000-0x05dfff:S, 0x05e000-0x05efff:S, 0x05f000-0x05ffff:S, 0x060000-0x060fff:S, 0x061000-0x061fff:S, 0x062000-0x062fff:S, 0x063000-0x063fff:S, 0x064000-0x064fff:S, 0x065000-0x065fff:S, 0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S, 0x069000-0x069fff:S, 0x06a000-0x06afff:S, 0x06b000-0x06bfff:S, 0x06c000-0x06cfff:S, 0x06d000-0x06dfff:S, 0x06e000-0x06efff:S, 0x06f000-0x06ffff:S, 0x070000-0x070fff:S, 0x071000-0x071fff:S, 0x072000-0x072fff:S, 0x073000-0x073fff:S, 0x074000-0x074fff:S, 0x075000-0x075fff:EFAILED at 0x00075000! Expected=0xff, Found=0x89, failed byte count from 0x00075000-0x00075fff: 0xf3f ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at 0x00070000! Expected=0xff, Found=0x40, failed byte count from 0x00070000-0x0007ffff: 0x79ab ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 2... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at 0x00070000! Expected=0xff, Found=0x00, failed byte count from 0x00070000-0x0007ffff: 0x79ab ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 3... 0x000000-0x07ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff: 0x3a0c2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 4... 0x000000-0x07ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff: 0x3a0c2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 5... not defined. Looking for another erase function. Trying erase function 6... not defined. Looking for another erase function. Trying erase function 7... not defined. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Good, writing to the flash chip apparently didn't do anything. Please check the connections (especially those to write protection pins) between the programmer and the flash chip. If you think the error is caused by flashrom please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!

1 0

AT25SF041 chip support
by adam 04 Dec '18

04 Dec '18

Hello, I'm trying to manage AT25SF041 using FT4232 MiniModule programmer. I'm using flashrom v1.0 on Linux 4.15.0-42-generic (x86_64) compiled from sources. Trying to erase chip at first and get this output: ./flashrom -p ft2232_spi:type=4232H,port=A -Ef Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found Atmel flash chip "unknown Atmel SPI chip" (0 kB, SPI) on ft2232_spi. === This flash part has status NOT WORKING 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! Read is not working on this chip. Continuing anyway. flashrom has no read function for this flash chip. Aborting. Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! According to https://www.flashrom.org/Supported_hardware page, this chip should be fully supported. Please advice. Thank you, Adam

2 4

FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski 04 Dec '18

04 Dec '18

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

3 3

Question about SIL3114 board with a N28F010-120 flash chip on it
by Peter Cost 30 Nov '18

30 Nov '18

Dear Reader, I have a SIL3114 PCI board with an Intel N28F010-120 flash chip on it, and I can't reprogram it since it lacks the 12V Vpp. I checked that there is no +12V connection on the PCI edge connector of the board and the VPP pin seems to be unconnected. My question is this. When I apply 12V Vpp to the chip will I then be able to reprogram the board with the Lattice (Silicon Image) dos utility or the flashrom utility. I am an experienced engineer, but my eprom day's are from way back in the 80's and early 90's and I have never done anything with flash proms other than reprogramming boards with the supplied software. Thanks for any response. Kind regards, Peter Cost

1 0

Support for On Semiconductor LE25U20AMB-AH 2Mbit Flash Memory, 10ms, 8 pin SOP-K
by Andrew Hancock 28 Nov '18

28 Nov '18

Trying to read a firmware BIOS HDD for an external USB 1TB Western Digital which uses a Support for On Semiconductor LE25U20AMB-AH 2Mbit Flash Memory,10ms, 8 pin SOP-K No support found on Website or versions 0.9.9 and version 1.0 running on Ubuntu Will there be any support for this chip ?

1 0

Heads Up: Ongoing layout-support work
by Nico Huber 25 Nov '18

25 Nov '18

Dear fellow flashrom contributors, I'll likely work on flashrom's layout support in the next few weeks. Part of it will be to finalize the work on per-region file arguments. There were multiple proposals for the command-line syntax without a real consent so far, [1] sums it up. If you have any preferences, please comment soon before things are set in stone. Nico [1] https://www.flashrom.org/Per_region_file_arguments

1 0

(no subject)
by Сергей Калиничев 25 Nov '18

25 Nov '18

2 1

Researching Lenovo IdeaPad 300-15ISK for Possible Future Support with FlashROM, and Later, CoreBoot
by moriel5 25 Nov '18

25 Nov '18

The title pretty much sums it up, however here are the details. I have managed to get a hold of my laptop's schematics due to them being leaked.I am currently working with someone over at Bios-Mods to modify the firmware ("unlocking it").Interestingly, this laptop (which I had already updated it's firmware), has no WiFi whitelist, and I had bought brand-new, about a month after it came out. The EC controller, an ITE IT8586E-LQFP, is connected via the LCP bus, and the touchpad, internal keyboard, and the NCT7718W thermal sensor are all connected to it, according to the schematics.I forget whether I have the same exact chip (though I believe it to be so) on my laptop, as 99% of the details match my laptop. The schematics refer to 2 SPI chips, an 8MB W25Q64FVSSIQ_SO8 on UC3 as the main SPI chip, and an 4MB W25Q32FVSSIQ_SO8 on UC6 as backup.I have only one SPI chip, an 8MB W25Q64FVS1011532 on UC3, with the UC6 solder point existing, so I could theoretically solder a backup SPI chip.A TPM chip, the Z32H320TC, also sits on the LCP bus, with a direct connection to the chipset, unlike the touchpad, internal keyboard and the thermal sensor, according to the schematics.I forget whether I have this TPM chip, but once again, I believe that it is so. The IdeaPad 300-15's motherboard is codenamed "Paris". It also (optionally) comes with an AMD dGPU, without direct connection to any graphical output.My specific model only has no dGPU. Can anyone help me with my research? I'm still not very experienced with the actual work regarding electronics, most of my experience is with researching them.If there is any more information required from the schematics, I'll gladly share them, and if anyone wants the schematics, I can send them over.

2 1

Output of motherboard Acer EM61SM/EM61PM
by Roberto Masutti 24 Nov '18

24 Nov '18

flashrom v0.9.5.2-r1546 on Linux 3.2.0-4-amd64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.7, GCC 4.6.2, little endian Command line (1 args): flashrom -V Calibrating delay loop... OS timer resolution is 1 usecs, 870M loops per second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1000 us, 10000 myus = 10016 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Acer" DMI string system-product-name: "Aspire T180" DMI string system-version: "R01-B4" DMI string baseboard-manufacturer: "Acer" DMI string baseboard-product-name: "EM61SM/EM61PM " DMI string baseboard-version: " " DMI string chassis-type: "Desktop" Found ITE Super I/O, ID 0x8726 on port 0x2e Found chipset "NVIDIA MCP61" with PCI ID 10de:03e0. Enabling flash write... This chipset is not really supported yet. Guesswork... ISA/LPC bridge reg 0x8a contents: 0x00, bit 6 is 0, bit 5 is 0 Flash bus type is LPC Found SMBus device 10de:03eb at 00:01:1 MCP SPI BAR is at 0x00000000 MCP SPI is not used. Please send the output of "flashrom -V" to flashrom(a)flashrom.org with your board name: flashrom -V as the subject to help us finish support for your chipset. Thanks. OK. Super I/O ID 0x8726 is not on the list of flash capable controllers. The following protocols are supported: LPC. Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x26, id2 0xff, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Found SST flash chip "SST49LF040B" (512 kB, LPC) at physical address 0xfff80000. Probing for SST SST49LF080A, 1024 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF160C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x49, id2 0x4d, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x49, id2 0x4d, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50LPW116, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V040C, 512 kB: probe_jedec_common: id1 0xbf, id2 0x50 Probing for Winbond W39V080A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x50 Found SST flash chip "SST49LF040B" (512 kB, LPC). No operations were specified. Restoring PCI config space for 00:01:0 reg 0x6d Restoring PCI config space for 00:01:0 reg 0x90 Restoring PCI config space for 00:01:0 reg 0x8c Restoring PCI config space for 00:01:0 reg 0x88

1 0

[PATCH] Do not abuse cs_bit
by Vicente Bergas 23 Nov '18

23 Nov '18

"cs_bit[s]" variable stores the bit location for Chip Select, as implied by the name. A new variable "cfg" is added for static configuration bits, like Output Enables. If outputs are disabled during operation, then the result will depend on the target having proper pull-up resistors, which is not always guaranteed. Signed-off-by: Vicente Bergas <vicencb(a)gmail.com> --- ft2232_spi.c | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/ft2232_spi.c b/ft2232_spi.c index 95584aa..fe7fcf8 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -84,18 +84,19 @@ const struct dev_entry devs_ft2232spi[] = { #define BITMODE_BITBANG_NORMAL 1 #define BITMODE_BITBANG_SPI 2 -/* The variables cs_bits and pindir store the values for the "set data bits low byte" MPSSE command that +/* The variables cs_bit, cfg and pindir store the values for the "set data bits low byte" MPSSE command that * sets the initial state and the direction of the I/O pins. The pin offsets are as follows: * SCK is bit 0. * DO is bit 1. * DI is bit 2. - * CS is bit 3. + * CS is at cs_bit. Default is bit 3. * * The default values (set below) are used for most devices: * value: 0x08 CS=high, DI=low, DO=low, SK=low * dir: 0x0b CS=output, DI=input, DO=output, SK=output */ -static uint8_t cs_bits = 0x08; +static uint8_t cs_bit = 0x08; +static uint8_t cfg = 0x00; static uint8_t pindir = 0x0b; static struct ftdi_context ftdic_context; @@ -209,10 +210,9 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low + * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ + pindir |= 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -229,8 +229,7 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -242,8 +241,7 @@ int ft2232_spi_init(void) /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -253,8 +251,7 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -338,8 +335,8 @@ int ft2232_spi_init(void) return -2; } else { unsigned int pin = temp + 4; - cs_bits |= 1 << pin; - pindir |= 1 << pin; + cs_bit = 1 << pin; + pindir = (pindir & ~0x08) | cs_bit; } } free(arg); @@ -425,7 +422,7 @@ int ft2232_spi_init(void) msg_pdbg("Set data bits\n"); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; + buf[1] = cfg | cs_bit; buf[2] = pindir; if (send_buf(ftdic, buf, 3)) { ret = -8; @@ -480,7 +477,7 @@ static int ft2232_spi_send_command(struct flashctx *flash, */ msg_pspew("Assert CS#\n"); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ + buf[i++] = cfg & ~cs_bit; buf[i++] = pindir; if (writecnt) { @@ -521,7 +518,7 @@ static int ft2232_spi_send_command(struct flashctx *flash, msg_pspew("De-assert CS#\n"); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; + buf[i++] = cfg | cs_bit; buf[i++] = pindir; ret = send_buf(ftdic, buf, i); failed |= ret; -- 2.19.1

1 0

Raspberry Pi spidev failure
by Sean Cross 22 Nov '18

22 Nov '18

Hi, I got this email from a mailing list somewhere. I'm experiencing an issue where I'm unable to flash using spidev on a Raspberry Pi. I'm running "4.14.79-1.rpi.fc27.armv7hl", which is based on Fedberry. I'm experiencing two issues: 1) I'm completely unable to access any SPI chips. This appears to be due to a bug in the kernel driver, which always yanks the CS line high despite the cs_change set to 0. A workaround I've come up with is to do everything as a single transaction, which seems to fix the problem on my device: diff --git a/linux_spi.c b/linux_spi.c index 3e60492..50f8220 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -183,14 +183,12 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned char *rxbuf) { int iocontrol_code; + char tmp_buf[readcnt + writecnt]; struct spi_ioc_transfer msg[2] = { { .tx_buf = (uint64_t)(uintptr_t)txbuf, - .len = writecnt, - }, - { - .rx_buf = (uint64_t)(uintptr_t)rxbuf, - .len = readcnt, + .rx_buf = (uint64_t)(uintptr_t)tmp_buf, + .len = writecnt+readcnt, }, }; @@ -203,15 +201,14 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, /* Just submit the first (write) request in case there is nothing to read. Otherwise submit both requests. */ - if (readcnt == 0) - iocontrol_code = SPI_IOC_MESSAGE(1); - else - iocontrol_code = SPI_IOC_MESSAGE(2); + iocontrol_code = SPI_IOC_MESSAGE(1); if (ioctl(fd, iocontrol_code, msg) == -1) { msg_cerr("%s: ioctl: %s\n", __func__, strerror(errno)); return -1; } + + memcpy(rxbuf, tmp_buf + writecnt, readcnt); return 0; } ------------------- 2) The other issue is that my device appears to want SPI_MODE_1. When I set SPI_MODE_1, it is able to detect and program the board, but fails to verify. The image that gets loaded still works, but I'm unsure of what's causing the issue. I can do some more debugging, but changing SPI_MODE_1 and applying the above-mentioned patch solves the issue for me. Sean

3 3

25FS406 and SST25WF040B have same ID's
by The_Raven Raven 15 Nov '18

15 Nov '18

Hi all Just for information: I have a chip with the label "25FS406" (i think it is a Sanyo "LE25FS406"). Flashrom detects the chip as "SST25WF040B". It seems that this chips have both the same ID's: id1 0x62 id2 0x1613 Chips are a little bit different in Voltage: LE25FS406: 1.65-2.10V SST25WF040B: 1.65-1.95V But i tested the LE25FS406 and it seems to work (read, erase and write with function 0) Greets

1 0

Intel Z97 chipset
by somebody 13 Nov '18

13 Nov '18

flashrom on Linux 4.18.18-041818-generic (x86_64) flashrom was built with libpci 3.5.2, GCC 7.3.0, little endian Command line (5 args): flashrom --programmer internal -V -o result.txt Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Desktop" DMI string system-manufacturer: "Gigabyte Technology Co., Ltd." DMI string system-product-name: "Z97-HD3" DMI string system-version: "To be filled by O.E.M." DMI string baseboard-manufacturer: "Gigabyte Technology Co., Ltd." DMI string baseboard-product-name: "Z97-HD3" DMI string baseboard-version: "x.x" Found ITE Super I/O, ID 0x8620 on port 0x2e Found chipset "Intel Z97" with PCI ID 8086:8cc4. 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... Root Complex Register Block address = 0xfed1c000 GCS = 0xc65: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007f3d65a61000 + 0x3800 0x04: 0xf008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done OP Type Pre-OP op[0]: 0x02, write w/ addr, none op[1]: 0x3b, read w/ addr, none op[2]: 0x20, write w/ addr, none op[3]: 0x05, read w/o addr, none op[4]: 0x9f, read w/o addr, none op[5]: 0x01, write w/o addr, none op[6]: 0x00, read w/o addr, none op[7]: 0x00, read w/o addr, none Pre-OP 0: 0x06, Pre-OP 1: 0x00 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x08: 0x00000000 (FADDR) 0x50: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x07ff0000 FREG1: BIOS region (0x00000000-0x007fffff) is read-write. 0x5C: 0x01ff0001 FREG2: Management Engine region (0x00001000-0x001fffff) is read-write. 0x60: 0x00007fff FREG3: Gigabit Ethernet region is unused. 0x64: 0x00007fff FREG4: Platform Data region is unused. 0x74: 0x00000000 (PR0 is unused) 0x78: 0x00000000 (PR1 is unused) 0x7C: 0x00000000 (PR2 is unused) 0x80: 0x00000000 (PR3 is unused) 0x84: 0x00000000 (PR4 is unused) 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xfc4010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=4 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05203b02 (OPMENU) 0x9c: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80802045 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002045 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x50444653 (FPB) Reading flash descriptors mapped by the chipset via FDOC/FDOD... done. === Content Section === FLVALSIG 0x0ff0a55a FLMAP0 0x02040003 FLMAP1 0x15100206 FLMAP2 0x26210120 --- Details --- NR (Number of Regions): 3 FRBA (Flash Region Base Address): 0x040 NC (Number of Components): 1 FCBA (Flash Component Base Address): 0x030 ISL (ICH/PCH Strap Length): 21 FISBA/FPSBA (Flash ICH/PCH Strap Base Address): 0x100 NM (Number of Masters): 3 FMBA (Flash Master Base Address): 0x060 MSL/PSL (MCH/PROC Strap Length): 1 FMSBA (Flash MCH/PROC Strap Base Address): 0x200 === Component Section === FLCOMP 0x64900044 FLILL 0xad604221 --- Details --- Component 1 density: 8 MB Component 2 is not used. Read Clock Frequency: 20 MHz Read ID and Status Clock Freq.: 50 MHz Write and Erase Clock Freq.: 50 MHz Fast Read is supported. Fast Read Clock Frequency: 50 MHz Dual Output Fast Read Support: disabled Invalid instruction 0: 0x21 Invalid instruction 1: 0x42 Invalid instruction 2: 0x60 Invalid instruction 3: 0xad === Region Section === FLREG0 0x00000000 FLREG1 0x07ff0000 FLREG2 0x01ff0001 --- Details --- Region 0 (Descr. ) 0x00000000 - 0x00000fff Region 1 (BIOS ) 0x00000000 - 0x007fffff Region 2 (ME ) 0x00001000 - 0x001fffff === Master Section === FLMSTR1 0xffff0000 FLMSTR2 0xffff0000 FLMSTR3 0xffff0118 --- Details --- Descr. BIOS ME GbE Platf. BIOS rw rw rw rw rw ME rw rw rw rw rw GbE rw rw rw rw rw Enabling hardware sequencing because some important opcode is locked. OK. Super I/O ID 0x8620 is not on the list of flash-capable controllers. The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 1 attached SPI flash chip with a density of 8192 kB. The flash address space (0x000000 - 0x7fffff) is divided at address 0x653000 in two partitions. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0x7fffff. In that range are 429 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xe8, id2 0x94, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xe8, id2 0x94, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x7f3d65a648a0

2 1

Dediprog programmer
by Stanislas BERTRAND 12 Nov '18

12 Nov '18

Hi, I am using the dediprog programmer to handle SPI flash on the ESP32. I have issue erasing the flash with dediprog ( but works fine with FTDI 2232H ). I am however able to write/program the flash with the dediprog. I am using the SF600Plus. > flashrom -p dediprog -E flashrom v1.0 on Linux 4.15.0-38-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). Found GigaDevice flash chip "GD25Q32(B)" (4096 kB, SPI) on dediprog. Erasing and writing flash chip... FAILED at 0x00002000! Expected=0xff, Found=0x00, failed byte count from 0x00002000-0x00002fff: 0x1000 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00007fff: 0x5e68 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0x6a98 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x2d112 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x2d153 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! > flashrom -p ft2232_spi:type=2232H,port=A -E flashrom v1.0 on Linux 4.15.0-38-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). Found GigaDevice flash chip "GD25Q32(B)" (4096 kB, SPI) on ft2232_spi. Erasing and writing flash chip... Erase/write done. Regards, Stan

1 0

verifying works, writing no device found
by M.Altschaeffel＠gmx.de 05 Nov '18

05 Nov '18

Hi, i have a problem with flashing a blank new bios chip. It´s a Macronix MXIC MX 25L3206E on a lenovo t430 mainboard. I successfully flashed the same mainboard with the orginal bios rom. Since i started using flashrom on a desolderd new chip the verifying process works 100 % at 20 try´s but the writing process failed because there is no EEPROM/flash device found. The /WP and /HOLD pin are high. For any help i would be thankful. Regards, Max

1 0

FOSDEM 2019 Hardware Enablement Devroom Call for Participation
by Paul Kocialkowski 03 Nov '18

03 Nov '18

Hi, The Hardware Enablement devroom is back for a second year at FOSDEM! It will take place on Sunday 3 February 2019. # Call for Participation We are opening the call for participation to our devroom, with the deadline for talk proposals set to Saturday 1 December 2018. # Devroom Scope This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * boot software * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development Despite this large scope, the focus of the devroom is set on highlighting the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. We also want to avoid purely commercial vague talks with marketing content, which leave little place to technical aspects. This year, we are looking to particularly highlighting free software outside of the operating system boundaries, especially with boot software as well as controller and peripheral firmwares. # Talk Format Since no Embedded devroom is taking place this year (and our devroom also covers embedded devices), we are expecting a significant number of submissions. In order to cover as much ground as we can, a new talk will be scheduled every half-hour, so accepted talks will follow this format: 20 minutes for the talk + 5 minutes for questions + 5 minutes for speaker setup We ask speakers to be present in the room before their talk so that speaker setup can go smoothly. # Submission Talks that fit in our devroom's scope can be submitted to the FOSDEM Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19 We encourage reusing accounts from previous years instead of creating new ones: * lost password: https://penta.fosdem.org/user/forgot_password * new Account: https://penta.fosdem.org/user/new_account/FOSDEM19 Here are a few guidelines when submitting a talk: * select the Hardware Enablement devroom as track * include an abstract for every submission and optionally a full description * make sure your contact details are up to date # Video Talks will be streamed live during the event and recorded. They will be available under a Creative Commons Attribution (BY) license later. # Contact For more information or questions about the devroom and this CFP, feel free to email hardware-devroom-manager at fosdem.org We're looking forward to lots of interesting proposals and hoping to see you all in Brussels at the event! Cheers, Paul for the Hardware Enablement devroom

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom