flashrom March 2017

flashrom@flashrom.org

21 participants
36 discussions

Re: [flashrom] Terminology to help distinguish different ways of using Flashrom

by David Hendricks

On Sun, Mar 19, 2017 at 10:42 AM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > Is there a term that unambiguously describes method 2(b)? Just to clarify, in that situation is the ROM is in a dedicated programmer such as http://www.dediprog.com/pd/universal-programmer/progmaster-u4 ? I'd describe it as "standalone."

4 years

Re: [flashrom] Terminology to help distinguish different ways of using Flashrom

by Patrick 'P. J.' McDermott

On 2017-03-18 at 18:47, Sam Kuper wrote: > My understanding is that there are, broadly speaking, two distinct > methods for using Flashrom: > > 1. The chip being read or flashed is part of the circuitry on the > motherboard that is hosting the OS that is running the Flashrom > instance. > > 2. The chip being read or flashed is *not* part of the circuitry on > the motherboard that is hosting the OS that is running the Flashrom > instance. Instead, that chip is being accessed via a programmer of > some kind (e.g. a Bus Pirate, or BeagleBone Black, or suchlike). > > This second method can be further subdivided: > > 2(a). The chip being read or flashed is connected to a circuit other > than the one being used to program it. For example, it might be a BIOS > EEPROM chip that was soldered to a motherboard by a PC manufacturer, > and which has not been removed from that motherboard. > > 2(b). The chip being read or flashed is *not* connected to a circuit > other than the one being used to program it. For example, it might be > a brand new chip that has been inserted into a programmer's ZIF socket > so that it can be programmed. > > > I would be grateful to know if terminology exists that would > unambiguously identify which method is being referred to, out of 1, > 2(a), and 2(b). > > The closest I have come to finding such a vocabulary is the page at > https://www.flashrom.org/ISP . This doesn't go very far, though. It > implies that, at least within the Flashrom project, the phrase > "in-system programming" *usually* refers to 2(a), but it might also > refer to 1. ISP (or sometimes ICSP) refers to 2(a). Method 1 would be internal programming (cf. flashrom's "internal" programmer), software programming, or specifically programming from the host CPU (vs. programming from another in-circuit flash master like the Intel Management Engine). Any of these terms are likely to be understood, though flashrom typically goes with "internal" programming. In any case, these flashing methods and terms also aren't specific to flashrom and can apply in other flash memory programming contexts. -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/

4 years

Terminology to help distinguish different ways of using Flashrom

by Sam Kuper

My understanding is that there are, broadly speaking, two distinct methods for using Flashrom: 1. The chip being read or flashed is part of the circuitry on the motherboard that is hosting the OS that is running the Flashrom instance. 2. The chip being read or flashed is *not* part of the circuitry on the motherboard that is hosting the OS that is running the Flashrom instance. Instead, that chip is being accessed via a programmer of some kind (e.g. a Bus Pirate, or BeagleBone Black, or suchlike). This second method can be further subdivided: 2(a). The chip being read or flashed is connected to a circuit other than the one being used to program it. For example, it might be a BIOS EEPROM chip that was soldered to a motherboard by a PC manufacturer, and which has not been removed from that motherboard. 2(b). The chip being read or flashed is *not* connected to a circuit other than the one being used to program it. For example, it might be a brand new chip that has been inserted into a programmer's ZIF socket so that it can be programmed. I would be grateful to know if terminology exists that would unambiguously identify which method is being referred to, out of 1, 2(a), and 2(b). The closest I have come to finding such a vocabulary is the page at https://www.flashrom.org/ISP . This doesn't go very far, though. It implies that, at least within the Flashrom project, the phrase "in-system programming" *usually* refers to 2(a), but it might also refer to 1. Can anyone point me towards, or suggest, a more accurate terminology? Many thanks!

4 years

Write access to wiki (Was: Re: Flashrom wiki "Supported programmers" page: Beaglebone Black not listed.)

by Sam Kuper

On 18/03/2017, Luc Verhaegen <libv(a)skynet.be> wrote: > On Sat, Mar 18, 2017 at 05:52:28PM +0000, Sam Kuper wrote: >> On 18/03/2017, Luc Verhaegen <libv(a)skynet.be> wrote: >> > Also, Sam, it's a wiki. >> >> Yes, but it has no obvious way to create an account ;) I guess I could >> request one, here on the mailing list, but [...] > > This is currently an issue with both coreboot and flashrom. People > cannot easily get a wiki account, and those more involved are all > whining that the wiki is not useful. There's a connection. I didn't find it an issue with Coreboot. https://www.coreboot.org/Special:UserLogin has information about how to request an account, and the process worked smoothly. https://www.flashrom.org/index.php?title=Special:UserLogin doesn't have information about how to request an account. *It should do.* But, as I say, the main reason I don't have an account on the Flashrom wiki is not that I couldn't guess how to request one, but rather that I haven't requested one. (I hope that if I did request one, and gave a good reason for doing so, the request would be granted.) Anyway, thanks :)

4 years

Re: [flashrom] Flashrom wiki "Supported programmers" page: Beaglebone Black not listed.

by Luc Verhaegen

On Sat, Mar 18, 2017 at 05:52:28PM +0000, Sam Kuper wrote: > On 18/03/2017, Luc Verhaegen <libv(a)skynet.be> wrote: > > On Sat, Mar 18, 2017 at 05:52:15PM +0100, Stefan Tauner wrote: > >> On Sat, 18 Mar 2017 16:45:14 +0000 > >> Sam Kuper <sam.kuper(a)uclmail.net> wrote: > >> The existence of that page is rather a mistake. It has been > >> unmaintained for a long time and should be replaced. Instead the > >> Supported_hardware page (which is generated from flashrom's source > >> semi-automatically) should note the BBB and directly link to its page. > >> Will be like that... sometimes in the future. > > > > Add a programmer category, and have the categories listed on the > > supported hardware page. > > Sounds reasonable. > > > Also, Sam, it's a wiki. > > Yes, but it has no obvious way to create an account ;) I guess I could > request one, here on the mailing list, but: > > - I don't own a BBB, so wouldn't be the ideal person to add any > documentation for that; and > > - it didn't seem sensible to request a wiki account, if I did not have > a good use to which to put it. This is currently an issue with both coreboot and flashrom. People cannot easily get a wiki account, and those more involved are all whining that the wiki is not useful. There's a connection. Luc Verhaegen. Who made the linux-sunxi wiki that useful.

4 years

Re: [flashrom] Flashrom wiki "Supported programmers" page: Beaglebone Black not listed.

by Stefan Tauner

On Sat, 18 Mar 2017 16:45:14 +0000 Sam Kuper <sam.kuper(a)uclmail.net> wrote: > The BeagleBone Black (aka "BBB") is recommended by the Libreboot > developers for use with Flashrom: "We recommend this product because > we know that it works well for our purposes and doesn't require any > non-free software." https://libreboot.org/docs/install/bbb_setup.html > > However, it is missing from the "Supported programmers" page of the > Flashrom wiki: https://www.flashrom.org/Supported_programmers > Hi! The existence of that page is rather a mistake. It has been unmaintained for a long time and should be replaced. Instead the Supported_hardware page (which is generated from flashrom's source semi-automatically) should note the BBB and directly link to its page. Will be like that... sometimes in the future. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 years

Flashrom wiki: what license is the content under?

by Sam Kuper

Hi folks, I have looked at a number of pages on the Flashrom wiki, though not all of them. None of the pages I have looked at mentioned the license (if any) under which their content is available. My understanding is that means that much (maybe all) of the documentation in the Flashrom wiki is proprietary (at least, in the overwhelming majority of jurisdictions). IANAL, though. If my understanding is incorrect, please could you point me towards information that should correct it? Alternatively, it would be great if the Flashrom wiki contributors could license the documentation in the wiki under one or more free culture licenses: https://freedomdefined.org/Licenses Ideally, Flashrom would license the content under the GFDL and CC BY-SA 3.0, making the content entirely license-compatible with content from Wikipedia and from the Stack Exchange network of websites. If you agree with the position I have taken above, please do reply to this thread to say so, especially if you have suggestions about how to best achieve the (re-)licensing. If you disagree with my position, please reply to explain your disagreement. Thanks, Sam P.S. For a parallel discussion of the license for Coreboot wiki content, please see: https://www.coreboot.org/pipermail/coreboot/2017-March/083607.html

4 years

Flashrom wiki "Supported programmers" page: Beaglebone Black not listed.

by Sam Kuper

The BeagleBone Black (aka "BBB") is recommended by the Libreboot developers for use with Flashrom: "We recommend this product because we know that it works well for our purposes and doesn't require any non-free software." https://libreboot.org/docs/install/bbb_setup.html However, it is missing from the "Supported programmers" page of the Flashrom wiki: https://www.flashrom.org/Supported_programmers This is quite a surprising omission, given the fact that it is recommended by Libreboot. It does seem to have been given some cursory attention on the Flashrom wiki here: https://www.flashrom.org/BBB . If anyone who has a BBB and has write access to the Flashrom wiki feels like fleshing out the latter page and linking it from the "Supported programmers" page, this would probably be very helpful for (potential) BBB owners who might not otherwise realise that Flashrom supports the BBB.

4 years

flashrom and W25Q128FV

by Connor Illian

the winbond W25Q128FV is listed as supported by flashrom. i have attempted to communicate with this chip via raspberry pi spidev as well as buspirate from ubuntu. i have one chip pulled from a working machine and three brand new blanks. no EEPROM is found no matter what i try with any chip. i cannot specify chip, and reading with -f results in an empty bin. i can remove the winbond chip from the socket and place a macronix mx25L6406e and flashrom identifies the chip immediately. i have compared data sheets between the macronix and winbond chips, and they are identical in terms of power, pinout, op codes, etc. the only difference is the macronix is 64mbit and the winbond is 128mbit. how can i proceed?

4 years, 1 month

Re: [flashrom] Layout Aware Flash Reading and Erase Blocks

by Nico Huber

On 16.03.2017 00:08, David Hendricks wrote: > On Fri, Mar 10, 2017 at 8:02 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >> >> Hi, >> >> I've just updated my solution to _the_ layout problem that I wrote last >> year [1]. I'm not asking for a review at this moment. There are at least >> two competing approaches that I want to discuss first (I couldn't start >> a discussion before I wrote it, due to time constraints). >> >> We can >> >> 1) walk over the given layout regions in an outer loop and >> walk over the erase blocks in each region in an inner loop >> >> This is how my patch tackles it. >> >> or >> >> 2) walk over all erase blocks in an outer loop and >> walk over the touched layout regions in an inner loop >> >> Thoughts? >> >> Both sounds easy to do but it gets really complicated when you account >> for a) regions that are not erase block aligned, b) our fallback to dif- >> ferent erase functions (and blocks thereby) and c) read-locks that might >> render a) impossible. > > > I think the second approach results in an extra layer of logic that really > isn't needed. With the first, we: > 1. We find what needs to change > 2. Select the appropriate block eraser Until now, I kept flashrom's fallback mechanism: it just tries all erase functions until one succeeds. I think that's very questionable though. So far I've only seen it triggered in two scenarios only: 1. Wrong flash chip selected (i.e. wrong opcode or wrong block size). => Might be a bug in flashrom that gets never reported. 2. Unreliable reads that made it look like the erase didn't work. => Fallback made things even worse, resulting in a full chip erase. So I'd agree to remove that fallback mechanism. > 3. Do the work. > > The second approach requires selecting a block erase size beforehand for > the outer loop, and that blockerase size might not be the one we want to > use to actually do the work (especially with the unaligned and optimized > cases). Agreed. In the long run, we'll want to choose the erase function more dynamically. > >> >> One pretty simple solution would be to exclude unaligned layout regions. >> How about this? anybody ever needed it? > > Historically some ChromeOS devices have had unaligned layout regions. > Generally speaking, excluding them would impose an artificial limitation on > the images that flashrom can handle that will just bite users. Layout > regions might be defined automatically by a firmware's build system without > awareness of a particular flash chip's blockerase sizes, or some users may > want to use unaligned regions to avoid wasting space (like putting multiple > small regions into a 64KB block). Ok, ok, I'm convinced. Never asked for it ;) > >> >> Another related thing is an optimization that I have in mind since ever >> I used flashrom: Selection of the biggest possible erase block size. >> Currently, if we erase/write say 16 blocks of 4KiB, we waste a lot of >> time because most chips would erase a 64KiB block much faster. If we >> ever add something like this, I guess it would be easier with approach >> 1). But maybe it'd be so invasive that it doesn't matter much... > > I'd like this as well, and agree that it would be easier with the first > approach. As far as invasiveness goes, the tricky part IMO is updating > portions of read logic to deal with unaligned layout regions to ensure data > outside the targeted region is restored, which requires knowing the > eraseblock size in advance. Otherwise you end up with hacks like this: > https://chromium-review.googlesource.com/c/240176/ I handle this at erase-block level (first code-block in read_erase_ write_block(), https://review.coreboot.org/#/c/17945/2/flashrom.c). It's not pretty but reduces the assumptions you have to take care of in higher levels. Nico

4 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom March 2017