January 2019 - flashrom - mail.coreboot.org

Re: [flashrom] New SPI NOR Flash product Support
by Stefan Tauner Aug. 15, 2019

Aug. 15, 2019

On Mon, 9 May 2016 20:46:18 -0700 David Hendricks <dhendrix(a)google.com> wrote: > Hi Victor, > From Flashrom's software perspective all chips with the same ID are > indistinguishable. > > Part number often includes characteristics such as package and thermal > tolerance which do not affect software compatibility. However, we will add the new names to the in-program (and hence wiki) database so that this new information becomes public. Thanks for the heads up, Victor. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 4

[announce] flashrom 1.0.1-rc1
by Nico Huber March 4, 2019

March 4, 2019

Hi flashrom fellows, I've just tagged `v1.0.1-rc1`. This is only a bug-fix release, obviously the first on our 1.0.x branch. The latest commit is rather new, so please test! Especially your layout use cases. During the past year, we've gathered a total of 6 fixes! Namely: * 6b9e934f linux_spi: Reduce maximum read chunksize Improves compatibility with older Linux kernels that interpreted the interface differently. * 30c4cecd Makefile: Disable `-Werror=deprecated-declarations` on release branch Just to be able to compile the 1.0.x branch on newer systems. * 5639af64 linux_spi: Hardcode default spispeed of 2MHz Default speed of kernel drivers isn't always sane (any more). * 993e162d dediprog: Fix small, unaligned reads An actual bug, discovered during experiments with arbitrary layouts. * ec8b8a7f board_enable.c: Fix dmi_match string for ThinkPad X201 Probably just wasn't tested before. * 69f96f60 Fix verification with sparse layouts A regression that sneaked into flashrom-1.0: When verifying the whole flash after a partial write with a sparse layout (i.e. a layout whose regions don't cover the whole chip), flashrom tried to verify against the wrong data and failed. Again, please test. If you don't use Git, you can find a tarball here: https://review.coreboot.org/cgit/flashrom.git/snapshot/flashrom-1.0.1-rc1.t… It still passes all my local build tests, see below for a full list. Best regards, Nico Build-tested in Docker images for the following targets: NetBSD 7.1 amd64 NetBSD 7.1 i386 centos:7.3-aarch64-clean centos:7.3-amd64-clean centos:7.2-amd64-clean fedora:25-x86_64 fedora:24-x86_64 fedora:25-ppc64le fedora:25-aarch64 debian-debootstrap:ppc64el-stretch debian-debootstrap:arm64-buster debian-debootstrap:armhf-stretch debian-debootstrap:mips-stretch debian-debootstrap:mipsel-stretch debian-debootstrap:amd64-sid debian-debootstrap:amd64-buster debian-debootstrap:amd64-stretch debian-debootstrap:i386-sid debian-debootstrap:i386-buster debian-debootstrap:i386-stretch ubuntu-debootstrap:arm64-bionic ubuntu-debootstrap:arm64-xenial ubuntu-debootstrap:amd64-bionic ubuntu-debootstrap:amd64-xenial ubuntu-debootstrap:i386-bionic ubuntu-debootstrap:i386-xenial alpine:aarch64-v3.8 alpine:armhf-v3.8 alpine:amd64-v3.8 alpine:amd64-v3.7 alpine:amd64-v3.6 alpine:i386-v3.8 alpine:i386-v3.7 alpine:i386-v3.6 djgpp:6.1.0

1 1

Using Meson to build flashrom
by Richard Hughes Feb. 6, 2019

Feb. 6, 2019

Hi all, First, happy new year and I hope you all had a great break. As some of you know, I've been working with 3mdeb for the last few months, with the aim of using libflashrom in fwupd to be able to flash firmware using the LVFS on various embedded systems. This /could/ include flashrom-compatible consumer hardware in the future, although I've not worked out all the details on how something like coreboot-on-thinkpad could be distributed automatically. Anyway, I digress. The fwupd project has to build in all kinds of odd targets, e.g. for odd endians, odd instruction sets, and in odd ways, e.g. installing with a prefix of /app for projects like flatpak. We also have other "robustness" guarantees and therefore have a comprehensive set of CI tests which enable a lot of warning flags and run linting and static analysis code like Coverity. This might explain my ongoing effort to fix up seemingly benign warnings. Rather than hack the hell out of Makefile (which I started to do initially) I ported the codebase to use the meson build-system. Meson is a(nother) next-generation build system used by a lot of open source projects ranging from low level libraries to desktop software. As part of the port, I also copied the CONFIG_ logic from the makefile, e.g. Option Current Value Possible Values Description ------ ------------- --------------- ----------- config_atahpt false [true, false] Highpoint (HPT) ATA/RAID controllers config_atapromise false [true, false] Promise ATA controller config_atavia true [true, false] VIA VT6421A LPC memory ... At the moment I'm using the meson port so I can include flashrom as a subproject to fwupd (as distros are not yet shipping libflashrom as a proper shared library) but 3mdeb is some way from being finished with libflashrom. I wondered if my work would be useful already to anyone else building flashrom on weird embedded architectures, or of it would be interesting to upstream with further work. The single commit which just adds 5 files can be found here: https://github.com/hughsie/flashrom/tree/wip/hughsie/meson Comments welcome. Richard.

3 4

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

Jan. 29, 2019

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 Jan. 28, 2019

Jan. 28, 2019

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 Jan. 26, 2019

Jan. 26, 2019

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 Jan. 25, 2019

Jan. 25, 2019

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 Jan. 23, 2019

Jan. 23, 2019

-------------------------------------------------------------------------------- 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 Jan. 20, 2019

Jan. 20, 2019

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 Jan. 18, 2019

Jan. 18, 2019

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