flashrom

flashrom@flashrom.org

5 participants
9161 discussions

[RFC]Improving layout handling
by Arthur Heymans 10 Feb '19

10 Feb '19

Hi Currently flashrom has support for 4 different mechanisms for providing layout, namely a plain layout file, on Intel platforms fetching the layout from IFD, using the coreboot specific FMAP layout either on file or on the flash. The way we handle those methods is awkward and does not scale very well. Adding new layout formats is quite awkward at the moment. The following could be improved on: - Currently each methods of providing a layouts is mutually exclusive so care must be taken. This makes the code flow hard to read in the classic_cli.c code, since some methods for fetching the layout first need flash access, while others don't. - layout.c file has a global variable for holding the layout entries that sometimes methods append entries to, sometimes gets overwritten with a new layout. - The mutual exclusiveness of getting layouts sometimes stands in the way of implementing features that requires multiple methods. For instance if your Intel FD says a region is RO it makes not sense try to override that region if your programmer is an Intel southbridge. - the layout entries array is too small. Some google FMAPs have more entries than our current MAX. While increasing the MAX is no issue, having a layout that can simply grow on demand seems preferable. Using a linked list seems to be ideal for this. Appending entries to linked list is also easy as opposed to appending to arrays of region entries. - afaict our manual says included regions cannot overlap but this is not enforced. For read and erase this does not matter much, for writes this seems like a bad idea or at least needs to be very clear on region takes precedence. So what I propose: - Use a single linked list for layouts (or regions in general) and pass the HEAD pointer around to append entries instead of using a global variable - make the methods of fetching the layout entries always append entries instead of outputting a new layout file. This could imply a libflashrom API change. (I don't have a strong opinion on this one as appending linked lists to each other is quite trivial) - Make methods for fetching layouts not exclusive, while checking that entries with the same name don't have different entries. E.g. if IFD says "bios" is 0x00000000:0x0020000 it should bail out if a layoutfile says something else. BTW with FMAP this can if desired also serve as a sanity check that the thing you are trying to flash also has the same FMAP as what resides on the flash. If this is implemented there is no real reason to block multiple layout files. - Fetch the layout entries in common places in cli_classic.c: layouts from files during the arg processing, layouts from flash where it is currently done (after programmer is ready) - Bail out on operations on overlapping regions, preferably in a function that appends layout entries, which can check for other things like double entries - get rid of the special case where no region + layout is included, but initialize the layout with a single entry spanning the whole flash. (get rid of struct single_layout) - Add some flags that can later be used to determine whether it is a good idea to try to write things, e.g. whether RO regions overlap with included regions on write operations. So the layout.h would look somethings like the following: =====layout.h===== struct romentry { chipoff_t start; chipoff_t end; bool included; bool write_possible; bool read_possible; char name[256]; }; /* Linked list entries */ struct flashrom_layout { struct romentry entry; struct flashrom_layout *next; }; /* No need for this anymore * struct single_layout { * struct flashrom_layout base; * struct romentry entry; * }; */ /* Linked list for include args. append when fetching layouts entries */ struct layout_include_args { char *name; struct layout_include_args *next; }; /* Deal with include args: * Add the included flag if everything is ok: no overlapping region, name * present in layout list. To be called after a layout entries are * gathered in the linked list. */ int process_include_args(const struct layout_include_args * const args, struct flashrom_layout *const l); =====layout.h===== So what do you think of this proposal? Kind regards Arthur Heymans

2 1

Using Meson to build flashrom
by Richard Hughes 06 Feb '19

06 Feb '19

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

Fwd: FOSDEM stand info
by Carl-Daniel Hailfinger 03 Feb '19

03 Feb '19

Hi everyone, TL;DR: - Our stand is in building Aw https://fosdem.org/2019/schedule/buildings/#aw - Stand buildup has to be finished Saturday 10:00 - Stand duty on Saturday ends 19:00 - Stand duty on Sunday starts 9:00 - Stand teardown starts at Sunday 17:00 - If you bring something, please tell me via email - I will bring wired ethernet (if we're lucky and get soemthing to plug in)+power - If you volunteer for stand duty, please tell me via email or show up sometime on Saturday so we can plan Sunday shifts. Have a great FOSDEM! Thanks! Carl-Daniel -------- Forwarded Message -------- From: Pieter De Praetere <pieter(a)fosdem.org> Subject: [FOSDEM standholders] Practical information for your FOSDEM stand To: standholders(a)lists.fosdem.org Dear FOSDEM stand organisers, Welcome to FOSDEM! We are very happy to welcome your project this year. Please take your time to read through this information sheet and the Code of Conduct (https://fosdem.org/2019/practical/conduct/). Stands are located in three buildings on the campus: the upper (+2) and lower (+1) corridors of the K building, the lower floor of H and the corridors of AW. The list of stands with their location is on the FOSDEM website (https:// fosdem.org/2019/stands/). Note that the exact location (in the building) will only be known closer to the event. During FOSDEM, the stands team and the building coordinators can be reached via the H or K infodesk. If it is very urgent, an emergency phone number is available: +32 2 788 74 74. Build-up ------------ Before the conference begins on Saturday, you will have time to set up your stand. We ask that you start around 8:30 with building up your stand and finish around 10:00 so all stands are ready by the time our visitors arrive. We will provide each stand with a table, chairs and a power cord. While we try to provide every stand with an individual power socket (Belgian E type - http://www.worldstandards.eu/electricity/plugs-and-sockets/), the layout of the building makes this sometimes impossible, so some stands will share a power cord. WiFi (best-effort) will be present in all buildings, but we cannot provide fixed (ethernet) internet. Please do not move the tables or chairs; the position of stands has to be agreed beforehand with ULB for fire safety reasons, so we have very little flexibility there. For the same reason, we cannot provide extra tables. To prevent damage to the buildings, please do not attach anything to the walls, windows etc. You can bring anything else (e.g. roll banners, a new, branded, table cloth, demo items etc.), as long as it fits on your table (180x80 cm). During the event ------------------------- For security reasons, we ask that there is always someone from the project present at your stand. This also gives visitors a more pleasant experience, as there will always be somebody at hand to answer questions. We ask that you do not distribute food or drinks; we do not have permission from the ULB to do so. Small quantities (e.g. cookies) are OK, but large-scale distribution or the selling of large amounts of food or drink is not allowed. You must vacate the building by 19:00 on Saturday. Buildings are closed during the night, but not guarded. You can store your valuable items in the cloak room during the night (after 18:00); but you should take your items out before 8. Sunday is a very busy day for the because many people will leave their luggage in the cloak room. Please keep the vicinity of your stand clean; life is better for everybody if the conference is nice and clean. Tear-down ---------------- When the event ends on Sunday, please clear up your stand and the immediate vicinity. There is a person responsible for every building, and they will be able to help you with any questions you might have regarding tear-down. The clean-up starts when the devrooms close, usually around 17:00. By 17:30, everything should be packed up so we can clean and close the buildings. All items you brought, you should take back. So all posters, stickers, banners etc. that you used to decorate your stand, or did not hand out to visitors, you should take with you or throw in the trash. You would make the clean-up volunteers very happy if you take the time to gently sweep the surroundings of your stand. Every building has a central "Collection point" where you should bring chairs, tables and all other FOSDEM equipment. You will also find brooms and garbage bags there. Please put chairs and tables on the correct carts, and all other FOSDEM equipment in the labeled boxes. It will save us a lot of time afterwards if everything is nicely packed up. We hope you will have a pleasant experience at FOSDEM and that your project will benefit from having a stand. Should you have any more questions or remarks, don't hesitate to contact us via stands(a)fosdem.org. Kind regards, The FOSDEM stands team

1 1

Intel HM86 - Lenovo L440 failure
by flashrom.org＠agowa338.de 03 Feb '19

03 Feb '19

Hi, I'm trying to dump the current firmware of my Lenovo L440, but it fails with `/dev/mem mmap failed:Operation not permitted`, even though I'm using the `iomen=relaxed` kernel parameter. ``` flashrom p1.0-141-g9cecc7e on Linux 4.20.6-arch1-1-ARCH (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.1 20181127, little endian Command line (5 args): flashrom --programmer internal -r current_bios.dump -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer get_mtd_info: device_name: "intel-spi", is_writeable: 0, numeraseregions: 0, total_size: 8388608, erasesize: 4096 Cannot open file stream for /dev/mtd0 No coreboot table found. Using Internal DMI decoder. No DMI table found. W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: fc. Found chipset "Intel HM86" with PCI ID 8086:8c49. 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 Error accessing ICH RCRB, 0x4000 bytes at 0x00000000fed1c000 /dev/mem mmap failed: Operation not permitted FAILED! FATAL ERROR! Error: Programmer initialization failed. ``` I'm running ArchLinux and the latest version of flashrom build out of git. As the chipseet is marked as untested, is there anything I can try? Best, Klaus Frank

2 1

Affordable SOIC8 SMT sockets for BIOS chips (15pcs / 36E + cheeap shipping)
by Ivan Ivanov 02 Feb '19

02 Feb '19

Just sharing our pleasant experience and nice find :) These SOIC8 SMT sockets for BIOS chips are too expensive at AliExpress (don't know why) - and to order them directly from Dediprog is economically inefficient because last time I checked they offered only overpriced express shipping - the cost of which is comparable to the price of sockets themselves! - But we are patient people and don't want to overpay that much for shipping regardless of its' speed. So we decided to order from this EU-based "The LAB eShop" : https://www.thelabeshop.com/en/Programmer-Emulators/SPI-Flash-Programmers/A… They are asking 36E (41US) for 15pcs sockets. Dediprog's price is 30US for 15pcs sockets, but "thanks" to their overpriced express shipping: "thelabeshop" prices are more affordable if you need just the sockets - they have an ordinary cheap post shipping method available with a tracking number, for 5 or 6. Although our first package has been lost, they kindly sent it again without any extra fees and this time it got delivered :) All 15 pcs sockets have these rectangular plastic caps and were reliably packet in a plastic ribbon to protect their fragile pins and for more convenience. If you need some photos we could share. What is also great about this "thelabeshop" is that, like aliexpress, they don't require you to use paypal (paypal adds unnecessary extra fees and has a horrible ethics / customer service). Payment could be done by a credit card. So if you need these rare SOIC8 sockets, "thelabeshop" price seems to be the most affordable. They also have SOIC16 sockets, although their expensive 58E price seems to be a mistake and maybe they could lower it for you if you would contact them - type "SOK-SPI-16W" at their search field if you are interested. And to find SOIC8, write "SOK-SPI-8W". These sockets could be very useful for routers or laptop motherboards, although you need a steady hand or ask professional to install them for you. Best regards, Ivan Ivanov

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom