flashrom

flashrom@flashrom.org

5 participants
9154 discussions

Lenovo ideapad 330S AMD FP4
by Balázs Vinarz 10 Sep '22

10 Sep '22

Hello there! I'm sending you the outputs of lspci and flashrom's output, when using internal flash. I hope you can do some improvement. flashrom v1.2 on Linux 5.15.53-1-lts (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 chipset "AMD FP4". Enabling flash write... FCH device found but SMBus revision 0x61 does not match known values. Please report this to flashrom(a)flashrom.org and include this log and the output of lspci -nnvx, thanks!. Could not determine chipset generation.PROBLEMS, continuing anyway ======================================================================== You seem to be running flashrom on an unknown laptop. Some internal buses have been disabled for safety reasons. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and https://flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.

1 0

FAILED: mAL10 Computer-on-Modules on Kontron Type 10 evaluation carrier board 2
by Graichen Michael 09 Sep '22

09 Sep '22

for your information =========== dev@mate:/tmp$ sudo flashrom -p internal --ifd -i bios -w coreboot.rom --noverify-all [sudo] Passwort für dev: flashrom v1.2 on Linux 5.15.0-40-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). No DMI table found. Found chipset "Intel Apollo Lake". Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0xaa to 0x89 failed. New value is 0xaa. SPI Configuration is locked down. Enabling hardware sequencing because some important opcode is locked. PROBLEMS, continuing anyway ======================================================================== You may be running flashrom on an unknown laptop. We could not detect this for sure because your vendor has not set up the SMBIOS tables correctly. Some internal buses have been disabled for safety reasons. You can enforce using all buses by adding -p internal:laptop=this_is_not_a_laptop to the command line, but please read the following warning if you are not sure. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and https://flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Reading ich descriptor... done. Using region: "bios". Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error between offset 0x00001000 and 0x00001fff (= 0x00001000 + 4095)! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. 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. Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Michael Graichen Research & Development ________________________________ T +49 631 34146-0<tel:+49%20631%2034146-0> michael.graichen(a)wipotec.com<mailto:michael.graichen@wipotec.com> <https://www.wipotec.com> wipotec.com<https://www.wipotec.com> | wipotec-wt.com<https://www.wipotec-wt.com> | wipotec-ocs.com<https://www.wipotec-ocs.com> WIPOTEC GmbH Adam-Hoffmann-Str. 26 67657 Kaiserslautern Germany [https://www.wipotec-ocs.com/fileadmin/wipotec-ocs/signature/linkedin.png] <https://www.linkedin.com/company/wipotec> [https://www.wipotec-ocs.com/fileadmin/wipotec-ocs/signature/facebook.png] <https://www.facebook.com/wipotec> [https://www.wipotec-ocs.com/fileadmin/wipotec-ocs/signature/youtube.png] <https://www.youtube.com/c/WIPOTECOCS> ________________________________ [cid:wipotec_38ce1105-f549-48fe-a3be-9e29d2b24123.gif]<https://www.wipotec.com><mailto:event@wipotec.com> Legal information: WIPOTEC GmbH | HRB 2317 Kaiserslautern Management: T. Düppre, U. Wagner, Dr. W. Schmitz, F. Köhler, J. Kühn You can find detailed data privacy guidelines<https://www.wipotec.com/en/policy/> on our website.

1 0

Introduction to the community - Dhiren
by dhiren serai 09 Sep '22

09 Sep '22

Hello everyone, I'm Dhiren Serai and I'm interested in contributing to one of GSOC 2022 Ideas called Design and implement new CLI based on libflashrom and extend the API as necessary . I'm new to C world but definitely not new to programming so I think I can adapt to this and get some hands dirty in Linux world. I'm also familiar with Linux concepts as I have been using it since 4 years so that shouldn't be a problem. I liked the gsoc 2022 idea which was proposed but as I'm not a student anymore I cannot do it as part of GSOC, but I have done open source contribution since 2 years so shouldn't be a problem for me to get started. I would like to work on this in the normal course of my time as a hobby. :D I'm excited to work on this. :D

2 3

Flash chip not identified
by Aagi Girish 08 Sep '22

08 Sep '22

Hi Team, We are trying to install coreboot firmware on our hardware for a customer requirement and the flashrom utility did not identify the flash chip. Attached the information that you have requested. Our hardware information can be found at the link below. Please let us know which programmer / flash chip needs to be selected from the list below the link. https://www.hyperscalers.com/quanta-qct-server-1u/D43K-1U-AMD-server-EPYC-q… -p | --programmer <name>[:<param>] specify the programmer device. One of internal, dummy, nic3com, nicrealtek, gfxnvidia, drkaiser, satasii, atavia, it8212, ft2232_spi, serprog, buspirate_spi, dediprog, developerbox, rayer_spi, pony_spi, nicintel, nicintel_spi, nicintel_eeprom, ogp_spi, satamv, linux_mtd, linux_spi, usbblaster_spi, pickit2_spi, ch341a_spi, digilent_spi, stlinkv3_spi. Thanks, Aagi [HS Signiatures] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hyperscalers.com_&d…> Aaromal Girish Appliance Engineer p +61 1300 113 112 Hyperscalers.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hyperscalers.com_&d…> aagi.girish(a)hyperscalers.com<mailto:aagi.girish@hyperscalers.com> [cid:image002.jpg@01D8C374.7EA5B000] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hyperscalers.com_O…> [cid:image003.jpg@01D8C374.7EA5B000] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hyperscalers.com_q…> [cid:image004.jpg@01D8C374.7EA5B000] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hyperscalers.com_p…> [cid:image005.jpg@01D8C374.7EA5B000] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hyperscalers.com_I…> Hyperscale x86 Tier 1 Original x86 Lab as a Service LaaS IP-Appliance Design

1 0

FCH device found but SMBus revision 0x61 does not match known values.
by Alex Ortiz 06 Sep '22

06 Sep '22

1 0

i have no video on my laptop screen, so i need to flash the bios blind
by Hamid Mazuji 31 Aug '22

31 Aug '22

i don't know if my screen is blank because of a hardware issue or setting, but i can not even access the bios. the screen is blank at the very start i came across flashrom and coreboot pages after a duckduck search, but i can't figure out what environment these programs are designed for, or how to use the programs. for example, i can't figure out if i can use these programs to flash a bios without any keyboard input (because there's no video) are there pages on what flashrom is and how to use it or what coreboot is, and how to use it i did look around, but these questions weren't part of the faqs

1 0

lash chip is in an unknown state
by Delevic 29 Aug '22

29 Aug '22

Hi, I just tried to flash bios in nvidia p106-100 with. But I get errors : sudo flashrom --programmer ch341a_spi -w p106v.rom flashrom v1.2 on Linux 5.15.0-46-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 Winbond flash chip "W25Q40EW" (512 kB, SPI) on ch341a_spi. Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x00000fff: 0x1000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x00007fff: 0x8000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0000ffff: 0x10000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0007ffff: 0x80000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0007ffff: 0x80000 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! What to do next ? Best Regards Delevic

2 2

Erase/write error
by domimoel＠web.de 27 Aug '22

27 Aug '22

2 1

flashrom dev meeting notes 26.08.22
by Felix Singer 26 Aug '22

26 Aug '22

# 25th Aug 2022, 6:00 - 7:00 UTC+0 Attendees: Alex, Felix, Evan, Anastasia, Edward ## Decisions Summary * A link pointing to the meeting will be added on the Contacts page. * We want to discuss the minimum required versions of our (build- )dependencies. We don’t want ifdefs checking for library versions in the code. When a programmer doesn’t support a library version, the build system should not enable it. ## Agenda * [aklm] Are there any objections if I will add info about this meeting on the Contacts page? * Clarify this is NOT a support forum, not a troubleshooting forum * [Felix] Rework the flash chips database / minimize the compiled version of flashchips.c in size * In most cases, embedded applications only need a small selection of the available flash chips. If we are able to shrink it somehow, this could free useful space for other applications or use cases. * One approach: Currently, flash chips are grouped by vendors. So add compiler flags enabling or disabling these. * Another approach: Rework the way flash chips are organized. * flashchips.c is pretty inflexible and it’s complicated to get this in a format so that flash chips can be listed on the website. * Thus, store flash chips in an JSON file (may be any other format), which opens lots of possibilities. * The website could just use the JSON and list the data. For flashrom itself, we could write a little script (and add this to the build system) which converts the JSON data to C code. This way, we also could filter for specific flash chip characteristics (protocols, vendor, name, …), in case only a group or some specific chips are wanted. * Another advantage: We could add an API to (lib-)flashrom so that the user can use their own JSON file and so the user can add new (or change) flash chips without recompiling flashrom very easily. So flash chips can be compiled into flashrom but they also can be loaded using the JSON format. * Edward: there are patches for review [https://review.coreboot.org/q/topic:declarative_flashchips.c_complete](http… * [Felix/Thomas] We should define minimum required versions of libraries and (build-)dependencies * [https://review.coreboot.org/c/flashrom/+/65919](https://review.coreboot.org… * Created a sheet to collect the versions * [https://review.coreboot.org/c/flashrom/+/66436](https://review.coreboot.org… * If defs is not great * If someone is using such an old libusb version, then ch341a programmer should not be built in at all * We want to hold the patch for a moment * TODO : create ticket to move the discussion there, add a comment to the patch 66436 , link the ticket >> [https://ticket.coreboot.org/issues/409](https://ticket.coreboot.org/issues/… * Programmer param discussion * Board enable for i2c * [Joursoir] Flashrom CLI should have bash-completion (auto-complete text with TAB key while typing a command). Task for new contributors/next GSoC. * Useful for new users * Can be smaller project or larger project, can be broken into several phases * Felix: Not supported by standard bash, needs one extra packet. But most systems have it anyway. * Joursoir: Might need a bit of planning, think how to structure bash * We need to agree on what’s the end goals * Flashchips: too many of them, let’s not include it * Edward: Start as simple as possible, and then see how it goes. * Everyone: A very good idea * Joursoir (Alex) is a contact person for the project

1 0

Unify flashrom range types
by Evan Benn 25 Aug '22

25 Aug '22

# Introduction The goal is to unify the integer type used for ranges. libflashrom has 2 ranges in the API: write protect (wp) ranges and layout ranges. The types for these are not consistent between wp and layout, between getters and setters, and between the API and the implementation. Additionally the types are different sized depending on the platform (ie size_t on 32 vs 64 bit). Demo: https://review.coreboot.org/c/flashrom/+/67004 # Background / Motivation Assertion: Flashrom only cares about fairly normal platforms (32 and 64 bit pointers). size_t: size_t is the C type returned by sizeof. It is an unsigned integer. Throughout the C library it is used as the type for counting the length of and indexing into arrays. It is at least 16 bits. It is often the same size as uintptr_t and void* but this is not required. uintptr_t: A C type large enough to hold a pointer. unsigned int: At least 16 bits, probably 32 bits on all the platforms we care about. uint32_t: Exactly 32 bit type, not required to exist (ie, flashrom won't compile on platforms where this doesn’t exist). usize: A rust type corresponding to uintptr_t. uintptr: A go type corresponding to uintptr_t. Go also has C.size_t. # Flashrom Today getsize -> size_t read/write/verify -> size_t implementation: unsigned int https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5… Based on the implementation using `unsigned int`, Flashrom probably only works with up to 32 bit sized flashes. layout_add_region -> size_t, (start, end) layout_get_region -> unsigned int (start, len) impl: uint32_t (start, end) https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5… These types are probably fine on 32 bit platforms where they are all the same. On 64 bit you could add a region that will be truncated / wrapped without warning. The get and add using different ranges; (start, end) and (start, len) is very confusing - I have already gotten this wrong several times while refactoring. wp_set_range -> size_t (start, len) wp_get_range -> size_t (start, len) impl: size_t (start, len) All consistent here. wp_ranges_count -> size_t wp_ranges_get_range -> unsigned int impl: size_t Changing the get_range to take a size_t seems like a simple fix here. This is unlikely to ever cause a bug but is a strange style. # Rust Bindgen can be told to treat size_t as usize. Without this flag a rust type for size_t is chosen for the platform (ie u32 on 32 bit, u64 on 64 bit). Only usize can be used to index slices in rust. # Proposal ## Goal Unify all the length types (internal and external) Unify all the range bounds ((start, len) vs (start, end)) Make bindings straightforward ## Non goal 16 bit platforms >32 bit sized flashes Change the libflashrom API and the flashrom internals to use uint32_t for all flash sizes and ranges. Keep size_t for host related sizes, eg the buffer size in flashrom_layout_read_fmap_from_buffer or flashrom_image_verify. Add a layout_add (start, len) method and try to deprecate the (start, end) method. This will make all of the methods use the same concept of range. The wp implementation uses (start, len) while the layout implementation uses (start, end). I do not propose to change this. In the rust fat bindings, use usize to represent all ranges and offsets. After libflashrom changes from the current implementation to uint32_t, the rust bindings must convert between u32 and usize. We will only support 32 and 64 bit usize, so this will be straightforward. The rust bindings will reject attempts to provide values > 32bit at runtime. # Alternatives Use uint64_t. This has the pro of supporting large SPI flash on 64 bit platforms. However this wont make large flash supported on 32 bit platforms, as single buffers are passed around for data access; flashrom_image_write (struct flashrom_flashctx *flashctx, void *buffer, size_t buffer_len, const void *refbuffer) Use size_t everywhere. Size_t makes some sense to use, as the implementation and API deals with full flash sized buffers, and they can only be indexed by size_t sized ranges anyway. For example flashrom would support 16 bit of flash on a 16 bit platform, and 64 bit of flash on a 64 bit platform. However, tying the usable flash size to the platform size doesn't really make sense and is likely to cause confusion, and we probably only care about 32 bit flash. Use a typedef, eg chipsize_t. I think this is reasonable internally but don't prefer it. It would theoretically allow a simple change to swap from 32 to 64 bit flashes. However C won't warn about code using the wrong type while they are 'compatible', see for example the functions using unsigned int and uint32_t interchangeably in the codebase already. And this won't really work for libflashrom, it's too messy to make the API function differently depending on library compile time choices, this really creates incompatible APIs with identical names. For supporting larger-than-size_t size data objects, see posix lseek64 and friends. Use u32 for the rust API. This makes sense as it pushes out-of-range errors into the user code. However it complicates a lot of usage as u32 constantly need to be converted into usize to do array indexing. https://review.coreboot.org/c/flashrom/+/67004

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom