[LinuxBIOS] Flashrom --layout fails badly

[Jeremy Jackson]

If it can't open the layout file, it just goes ahead and flashes the
whole part.

Perhaps what the user (not naming names here) would prefer is for it to
print an error message and stop.

Just writing an email so I don't forget.

[Stefan Reinauer]

* Jeremy Jackson  [070413 20:30]:
> If it can't open the layout file, it just goes ahead and flashes the
> whole part.
>
> Perhaps what the user (not naming names here) would prefer is for it to
> print an error message and stop.
>
> Just writing an email so I don't forget.

Good point. I updated it so it exits.

[Jeremy Jackson]

I'm also curious about the incrementing addresses it displays.  When
using a layout file, I'd expect it to skip certain addresses, or start a
new line when starting/stopping each range, perhaps like

Programming (segment name) 0x000100 (increments a number of sectors)
Done programming (segment name) 0x001f00
Skipping blank area 0x2000
Done skipping blank area 0x2fff
Programming (other seg name) 0x3000
Done programming (other seg name) 0x3fff
Skipping (another seg name) 0x4000
Done skipping (other seg name) 0x4fff

etc.  just getting my thought down before it goes away again.

Cheers,

Jeremy

On Sat, 2007-04-14 at 22:27 +0200, Stefan Reinauer wrote:
> Jeremy Jackson  [070413 20:30]:
> > If it can't open the layout file, it just goes ahead and flashes the
> > whole part.
> >
> > Perhaps what the user (not naming names here) would prefer is for it to
> > print an error message and stop.
> >
> > Just writing an email so I don't forget.
>
> Good point. I updated it so it exits.

[Stefan Reinauer]

* Jeremy Jackson  [070508 21:11]:
> I'm also curious about the incrementing addresses it displays.  When
> using a layout file, I'd expect it to skip certain addresses, or start a
> new line when starting/stopping each range, perhaps like

Very true. That part is quite a bit fake in flashrom. It reads the image
from disk, reads the "skipped" areas from the flash chip into the image
and then flashes the complete image.

It would be easy to fix, given a bit of time: The only tested path is
erasing all of the chip and then rewriting it. It would be much better
to respect the flash hardware sectors/blocks here. The changes required
to the code are mostly adding/fixing block erase functions for all
supported chips.

The nasty part is testing: All the flash devices would require
retesting with full and partial images.