operation details and future changes (was: flashrom ignoring ROM layout region)

[Stefan Tauner]

On Fri, 8 Feb 2013 11:08:21 +0100
Mark Marshall <markmarshall14(a)gmail.com> wrote:

Hi Mark,

  I too would love for these changes to go in.  I'm
currently working with a
 64MB flash, and
 I've got a number of problems, one of which is that flashrom tries to read
 the entire flash
 before doing anything (which will never be what I want...).
It does so to be able to skip blocks that have the wanted content
already and to be able to tell you if anything has changed in the case
of an error (not so important on external programmes, but very
interesting for people writing their live BIOSes and seeing errors).

Usually reading does take way less time than erasing/writing or might
even speed up the whole process. ATM there is no way to disable this
behavior but we plan to do so and IIRC a part of the mentioned patch set
is a first step into that direction.

  The other problems are:
 - That most of flashrom seems to be limited to 2^24 address bits.
   (this is relatively easy to fix)
We will see about that :) We are of course aware that this is needed
quite soon. Do you want to help us with this (mostly testing, but if
you like you can also try to create the needed patch)?

  - That flashrom thinks a page is always 256 byes (I
think I've found
   most cases of this, but I'm not sure.  What's the granularity flag
   for?
The flag is there to fix exactly this :)
See also http://patchwork.coreboot.org/patch/3757/
Not many chips need this and so we never moved into this direction...
do you really need it?

  I've also found that flashrom doesn't always
do what I expect, and I'm not
 sure if this is
 by design or not.  for instance, if I want to erase my entire flash chip,
 it ends up calling
 the sector erase on each sector, not by doing a chip-erase?  Are these
 types of things
 written down anywhere?
We try to erase the smallest possible blocks first (in order of the
eraser array of the chip definition(s) in flashchips.c. This potentially
allows to skip writing of block as explained above. It is of course
rather useless for the -E/--erase operation, but the code is shared and
no one complained yet IIRC (or sent a patch). Most of these details are
not documented I think, but some are (in the manpage). Patches for the
manpage are welcomed. Everyone is invited to edit the wiki too :)
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

[Mark Marshall]

Hi.

On 8 February 2013 16:44, Stefan Tauner
<stefan.tauner(a)student.tuwien.ac.at>wrote;wrote:

  On Fri, 8 Feb 2013 11:08:21 +0100
 Mark Marshall <markmarshall14(a)gmail.com> wrote:

 Hi Mark,

  The other problems are:
 - That most of flashrom seems to be limited to 2^24 address bits.
   (this is relatively easy to fix)
 We will see about that :) We are of course aware that this is needed
 quite soon. Do you want to help us with this (mostly testing, but if
 you like you can also try to create the needed patch)?
I've got some patches that work here, but one of them involves just
commenting out the code in spi.c::spi_chip_read!  I don't really understand
what it thinks it's checking for (which isn't strictly true, it seems to be
to do
with accessing the flash through a memory window, which happens for a
motherboard BIOS.)

I'll neaten them up and post them next week.


  - That
flashrom thinks a page is always 256 byes (I think I've found
   most cases of this, but I'm not sure.  What's the granularity flag
   for?
 The flag is there to fix exactly this :)
 See also http://patchwork.coreboot.org/patch/3757/
 Not many chips need this and so we never moved into this direction...
 do you really need it?
I don't know if I need it.  I guess not actually, as my page size is 512,
and it should all work with the code for 256?  It might be faster as 512,
but I
don't care about that small difference.


  I've also
found that flashrom doesn't always do what I expect, and I'm
 not
  sure if this is
 by design or not.  for instance, if I want to erase my entire flash chip,
 it ends up calling
 the sector erase on each sector, not by doing a chip-erase?  Are these
 types of things
 written down anywhere?
 We try to erase the smallest possible blocks first (in order of the
 eraser array of the chip definition(s) in flashchips.c. This potentially
 allows to skip writing of block as explained above. It is of course
 rather useless for the -E/--erase operation, but the code is shared and
 no one complained yet IIRC (or sent a patch). Most of these details are
 not documented I think, but some are (in the manpage). Patches for the
 manpage are welcomed. Everyone is invited to edit the wiki too :)
I was wondering about creating a more detailed structure of both the
contents of
the ROM and the (set of) files that the user was trying to program.  Then
we
could read back from the flash only for the bits that we needed. Any
thoughts?

Thanks for your help, and I'll try to post more next week.

Regards,

Mark M?



  --
 Kind regards/Mit freundlichen Grüßen, Stefan Tauner