flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Flashing MX 25L12873F on MSI board via Raspberry Pi SPI
by Fabian Köster 25 Jan '18

25 Jan '18

Hello list, I recently tried to update the BIOS of my MSI H87-G43 [1] from an usb disk using the "M-Flash" method. The update seemed to have succeeded, but now the board does not do anything at bootup anymore. No screen output, no beeping. At first, one of the LEDs (i guess HDD activity) blinked periodically, but after a few restarts it does not even do that anymore. After doing some research I found some guides abouting flashing the bios chip from outside. One article especially captured my interest, which described how to access the flash chip via the JSPI1 header on the mainboard from a Raspberry Pi [2]. I followed that guide, but I cannot manage to get a connection to the chip. I found out the used chip is a MX 25L12873F [3], but it is not listed as supported on [4], does this mean it will not work with Flashrom? Or is maybe something wrong with my wiring? In contrast to the description of the JSPI1 MSI connector on [5] the connector on my board has 12 pins, so I was a little bit confused. I am new to this topic and very thankful for any help! Regards Fabian [1] https://de.msi.com/Motherboard/H87-G43.html [2] https://forum-en.msi.com/index.php?topic=289550.0 [3] http://www.bios-chip24.com/MXIC-MX-25L12873F-M2I-10G-128MBit-SPI-Flash-SOIC… [4] https://www.flashrom.org/Supported_hardware [5] https://www.flashrom.org/MSI_JSPI1

3 12

CrOS flashrom compatibility and upstreaming of CrOS features
by Nico Huber 25 Jan '18

25 Jan '18

Hey folks, during review of commits that port per-region file arguments [1] from CrOS flashrom over here, we ran into a discussion about the command line interface changes. The basic question that arose is Do we want to maintain full CLI compatibility to CrOS flashrom? This would have the upside, that it would ease remerging of the two flashrom versions (in some unknown future). And anybody currently using CrOS flashrom could transition more smoothly. OTOH, depending on how the compatibility is achieved, it might increase the costs for review and development heavily (for a project with 0 spare resources). To not have to discuss this each and every time when some non-trivial feature is ported over from CrOS, I'd like to have some opinions, how valuable CLI compatibility is to you all and how we want to achieve it. I have currently some alternative ideas in mind that I'll sketch below. Feel free to add other ideas or just to comment them. 1) Integrate CLI changes from CrOS into flashrom proper's CLI. This turned out to be much harder than one might initially think: For the mentioned patches, it means that a lot of additional deve- lopment has to happen: * Restore internal behaviour in flashrom that became incompatible. * Add appropriate sanity checks for the arguments passed (yes, flashrom proper does such). * Discuss and review the additional code, too. It also restricts us to the design choices already made for CrOS flashrom and makes our review process kind of mindless. It does, however, get the job done, and everybody could just run `make` and wouldn't have to care if he's using one version of flashrom or the other. 2) Design our own interface for flashrom proper, but keep internal compatibility for an alternate CLI. It would allow us to make our own design choices at the interface level. A steady implementation might be much easier to accomplish if we keep things simple. Somebody would have to maintain an additional, CrOS compatible CLI. We could be more lax regarding to sanity checks in the alternate CLI, to speed up development. But, everybody already familiar with the CrOS flashrom CLI might get confused until he finds the alternative CLI. 3) Design our own implementation; provide compatibility with a wrapper script. The basic function of flashrom should be clear: read, write or verify the contents of a flash chip. Everything else (like com- bining multiple files in complex ways) shouldn't add unnecessary complexity to flashrom, and can likely be done in cleaner ways with other tools. In other words, we could try to keep flashrom more like a UNIX tool. IMHO, this would allow us to get new features in faster. If some- body sees a better way to implement a feature, we can just do it. Writing a wrapper script seems much easier too me than main- taining compatibility and safety in an unnecessary complex C program. Same as 2), people used to the other interface would have to learn a new one (or use the wrapper). So please let me know what you think, folks ;) Nico [1] 23021, 23022 and related 23353 in https://review.coreboot.org/

2 1

W25Q40.W Chip tested -> OK
by The_Raven Raven 24 Jan '18

24 Jan '18

Hi I have tested Chip "W25Q40.W" (found on a HDD). Chip works fine. Test Steps: - Read - Erase - Written Data1 - Written Data2 (overwritten) Data1 and Data2 generated with "dd" from "/dev/urandom". Greets

1 0

Re: [flashrom] BIOS-Flash failed @ Asus A55BM-E
by Nico Huber 23 Jan '18

23 Jan '18

Hi Lukas, On 23.01.2018 10:02, Lukas Blacha wrote: > I have tryed to flash my BIOS via a Raspberry Pi. I have installed > flashrom via the apt-get repo. At the attachments you will find the > flashlog. you have to pass a reasonable speed (usually 1MHz to 30MHz, depending on your setup) via the spispeed parameter to linux_spi (see flashrom manpage and https://flashrom.org/FAQ). Nico

1 0

PLS add the chip WINBOND 25Q256FVFG to surport base
by 蔺红波 23 Jan '18

23 Jan '18

HI,the chip WINBOND 25Q256FVFG is not surported to your program.PLS add it .Thank you. Skywolflin.

2 1

BIOS-Flash failed @ Asus A55BM-E
by Lukas Blacha 23 Jan '18

23 Jan '18

Hello, I have tryed to flash my BIOS via a Raspberry Pi. I have installed flashrom via the apt-get repo. At the attachments you will find the flashlog. Thank you for your help. On Chip print: GigaDevice GD25B64BPIG Greetings from Germany Lukas

1 0

LE25FU406C Chip tested -> OK
by The_Raven Raven 23 Jan '18

23 Jan '18

Hi again Tested again with raspberry pi (linux_spi). All tests ok. Works fine. Greets

1 0

Pm25LD040(C) Chip tested -> OK
by The_Raven Raven 23 Jan '18

23 Jan '18

Hi I have tested Chip "Pm25LD040(C)" with Raspberry Pi (linux_spi). It is a "Pm25LD040" (without "C"). Chip works fine. Test Steps: - Readed - Erased - Written Data - Written Data1 (overwritten) Data and Data1 generated with "dd" from "/dev/urandom". Greets

1 0

Flash memory AT26SF081A
by Miloslav Semler 22 Jan '18

22 Jan '18

Hello, recently I wanted to flash AT26SF081A and it worked with same parameters like AT26DF081A, except that I had to modify ID of chip to 0x8501. Otherwise the programming of memory worked well. Can you add the chip to database. Thanks. Miloslav

1 0

Re: [flashrom] KabyLake Utilization of flashrom for BIOS update with two devices totalling 32MB.
by Nico Huber 22 Jan '18

22 Jan '18

Hello Simon, On 19.01.2018 16:23, Furlong, Simon wrote: > Can you help explain as two why the SPI region fails to program > (specifically due to the mmap failure)? the attempt to map the flash chip into flashrom's user-space is a very old relict that, I assume, doesn't apply to SPI programmers at all. It's likely that the mapping just fails because there is no contiguous 32MiB space at that address (IIRC, on Intel systems, at most 16MiB of the BIOS flash is memory mapped). You may find more information about why the mapping is rejected in your system log (e.g. dmesg). To get rid of the attempt to map, you'd have to patch and build flashrom by yourself. Here is a patch that might fix the issue for you [1]. If you use Git, you can simply check it out with the following commands: git fetch https://review.coreboot.org/flashrom.git refs/changes/44/23344/1 git checkout FETCH_HEAD Some information about build requirements can be found here [2]. Hope that helps, Nico [1] https://review.coreboot.org/23344/ [2] https://flashrom.org/Downloads

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom