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."
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/
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!
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 :)
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.
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
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
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.
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?
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