[adding flashrom@flashrom.org to CC]
On 28.09.2010 22:16, Aurélien wrote:
On Tue, Sep 28, 2010 at 9:55 PM, Peter Stuge peter@stuge.se wrote:
Aurélien wrote:
I tried to make a patch which reads from /dev/mem directly in 2 ways:
- mmap()ing /dev/mem, but it seemed that it would be too specific a
modification to be accepted.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
You're right, splitting the feature in two tools seems much more correct. This way we can extract the ROM image, then extract the specific payload.
Well, for that purpose it's much better to simply use flashrom.
Probably, but flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
and is less integrable that just reading like this. I don't need much portability between mainboards anyways.
Yes, libflashrom is still not completely done. Most of the parts are there, and we even have a bunch of different frontends, but the exported interface needs to be decided upon before we start offering libflashrom
In the general case however, you are right, the flashrom method seems much more robust.
Thanks!
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
//Peter
On 29.09.2010 01:32, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
That would break some Winbond LPC flash chips which require a few milliseconds of delay between JEDEC toggle reads on erase. And we also noticed that some SPI chips will react badly (corruption) to a too tight RDSR instruction schedule.
flashrom on libpayload uses the libpayload-provided delay functions and skips calibration. Given that LPC/FWH/SPI flash chips usually tolerate longer than expected delays without problem, you could hook up programmer_delay to udelay and save a second or so for calibration if you don't need parallel flash.
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
Network cards with parallel flash would be classified as "local bus"?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
That would break some Winbond LPC flash chips which require a few milliseconds of delay between JEDEC toggle reads on erase. And we also noticed that some SPI chips will react badly (corruption) to a too tight RDSR instruction schedule.
Yay. I guess they would be disabled too, unless calibration has run.
Given that LPC/FWH/SPI flash chips usually tolerate longer than expected delays without problem, you could hook up programmer_delay to udelay and save a second or so for calibration if you don't need parallel flash.
That sounds good!
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
Network cards with parallel flash would be classified as "local bus"?
I believe bridges can make things more complicated. The assumption is that any bus master will always ensure correct timing for the bus where the chip is connected. You mentioned that there are exceptions, to that, but I think it'll hold in general. A bridge in a PCI chip that decodes into ROM may or may not ensure correct timing. I think it would have to be set on a per-chip basis.
//Peter
-
Carl-Daniel Hailfinger -
Peter Stuge