Current flashrom forces that the loaded filesize must equal the romsize. If you are using an external programmer then this may not be true.
How deeply wired is this assumption? I'd like to bypass those checks it if the -p option is used.
On 18.11.2010 16:51, Richard Smith wrote:
Current flashrom forces that the loaded filesize must equal the romsize. If you are using an external programmer then this may not be true.
Can you give an example use case?
How deeply wired is this assumption? I'd like to bypass those checks it if the -p option is used.
The underlying problem is that flashrom can't know if you want top-aligned or bottom-aligned write. If you only want to write a part of the chip, you can do that with the layout feature, but that still requires an image file with full size. Suggestions are welcome on how flashrom should detect the alignment wanted by the user. (The famous "DoWhatIMean" function has not been implemented yet.)
Regards, Carl-Daniel
On 11/18/2010 12:48 PM, Carl-Daniel Hailfinger wrote:
On 18.11.2010 16:51, Richard Smith wrote:
Current flashrom forces that the loaded filesize must equal the romsize. If you are using an external programmer then this may not be true.
Can you give an example use case?
Certainly since I'm exactly this case. The EnE EC chips that I use KB3700,KB3930 have an address space of 64k. However, these parts can share space with the system firmware and the EC itself can use an SPI part that is much bigger (I forget exactly how big) The OLPC system used an 8Mbit part on both XO-1 and 1.5.
When doing EC work I'm only interested int the lower 64k and thats the size of file my build system generates. The 64k blob gets sucked into the larger firmware image when we build the system firmware.
On the XO 1.75 the EC has its own SPI flash but you can't get a 64k SPI flash so its 128k.
When I want to program the EC directly with a programmer I only want to program the lower 64k.
Since my generated files are 64k in size flashrom won't load them unless I change my build system to generate files that match the size.
How deeply wired is this assumption? I'd like to bypass those checks it if the -p option is used.
The underlying problem is that flashrom can't know if you want top-aligned or bottom-aligned write. If you only want to write a part of the chip, you can do that with the layout feature, but that still requires an image file with full size. Suggestions are welcome on how flashrom should detect the alignment wanted by the user. (The famous "DoWhatIMean" function has not been implemented yet.)
The answer is don't try to guess. Always use bottom aligned. Thats what the --offset command is for. Every programmer I've used for the last 20 years (probably about 10) works this way. Its expected and intuitive. You feed it a file and a chip type (if it can't autodetect) and it just programs that data starting at address zero.
On 18.11.2010 21:14, Richard A. Smith wrote:
On 11/18/2010 12:48 PM, Carl-Daniel Hailfinger wrote:
On 18.11.2010 16:51, Richard Smith wrote:
Current flashrom forces that the loaded filesize must equal the romsize. If you are using an external programmer then this may not be true.
Can you give an example use case?
Certainly since I'm exactly this case. The EnE EC chips that I use KB3700,KB3930 have an address space of 64k. However, these parts can share space with the system firmware and the EC itself can use an SPI part that is much bigger (I forget exactly how big) The OLPC system used an 8Mbit part on both XO-1 and 1.5.
When doing EC work I'm only interested int the lower 64k and thats the size of file my build system generates. The 64k blob gets sucked into the larger firmware image when we build the system firmware.
On the XO 1.75 the EC has its own SPI flash but you can't get a 64k SPI flash so its 128k.
When I want to program the EC directly with a programmer I only want to program the lower 64k.
I see. On x86, you would only want to program the upper 64k.
Since my generated files are 64k in size flashrom won't load them unless I change my build system to generate files that match the size.
How deeply wired is this assumption? I'd like to bypass those checks it if the -p option is used.
The underlying problem is that flashrom can't know if you want top-aligned or bottom-aligned write. If you only want to write a part of the chip, you can do that with the layout feature, but that still requires an image file with full size. Suggestions are welcome on how flashrom should detect the alignment wanted by the user. (The famous "DoWhatIMean" function has not been implemented yet.)
The answer is don't try to guess. Always use bottom aligned.
This would introduce breakage for the main use case of flashrom: x86 BIOS. If you flash a smaller image to an x86 BIOS chip, it must always be top aligned.
Thats what the --offset command is for. Every programmer I've used for the last 20 years (probably about 10) works this way. Its expected and intuitive. You feed it a file and a chip type (if it can't autodetect) and it just programs that data starting at address zero.
It may be expected by people working with programmers, but how can we tell x86 users with no standalone programmer experience that flashing smaller images (with the suggested bottom alignment) bricks their systems by default?
Regards, Carl-Daniel
On 11/18/2010 03:30 PM, Carl-Daniel Hailfinger wrote:
Thats what the --offset command is for. Every programmer I've used for the last 20 years (probably about 10) works this way. Its expected and intuitive. You feed it a file and a chip type (if it can't autodetect) and it just programs that data starting at address zero.
It may be expected by people working with programmers, but how can we tell x86 users with no standalone programmer experience that flashing smaller images (with the suggested bottom alignment) bricks their systems by default?
I'm not proposing that the default behavior change. The current behavior is perfectly correct for the flash-my-PC-BIOS case where if things go wrong you are dead.
I'm talking about the external programmer case. It would be contingent on the -p option. If you are using an external programmer then you can't brick your system and you aren't a casual user.
On Thu, Nov 18, 2010 at 12:30 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 18.11.2010 21:14, Richard A. Smith wrote:
On 11/18/2010 12:48 PM, Carl-Daniel Hailfinger wrote:
On 18.11.2010 16:51, Richard Smith wrote:
Current flashrom forces that the loaded filesize must equal the romsize. If you are using an external programmer then this may not be true.
Can you give an example use case?
Certainly since I'm exactly this case. The EnE EC chips that I use KB3700,KB3930 have an address space of 64k. However, these parts can share space with the system firmware and the EC itself can use an SPI part that is much bigger (I forget exactly how big) The OLPC system used an 8Mbit part on both XO-1 and 1.5.
When doing EC work I'm only interested int the lower 64k and thats the size of file my build system generates. The 64k blob gets sucked into the larger firmware image when we build the system firmware.
On the XO 1.75 the EC has its own SPI flash but you can't get a 64k SPI flash so its 128k.
When I want to program the EC directly with a programmer I only want to program the lower 64k.
I see. On x86, you would only want to program the upper 64k.
Since my generated files are 64k in size flashrom won't load them unless I change my build system to generate files that match the size.
How deeply wired is this assumption? I'd like to bypass those checks it if the -p option is used.
The underlying problem is that flashrom can't know if you want top-aligned or bottom-aligned write. If you only want to write a part of the chip, you can do that with the layout feature, but that still requires an image file with full size. Suggestions are welcome on how flashrom should detect the alignment wanted by the user. (The famous "DoWhatIMean" function has not been implemented yet.)
The answer is don't try to guess. Always use bottom aligned.
This would introduce breakage for the main use case of flashrom: x86 BIOS. If you flash a smaller image to an x86 BIOS chip, it must always be top aligned.
Thats what the --offset command is for. Every programmer I've used for the last 20 years (probably about 10) works this way. Its expected and intuitive. You feed it a file and a chip type (if it can't autodetect) and it just programs that data starting at address zero.
It may be expected by people working with programmers, but how can we tell x86 users with no standalone programmer experience that flashing smaller images (with the suggested bottom alignment) bricks their systems by default?
Regards, Carl-Daniel
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
I tend to agree with Carl-Daniel here. It's also worth noting that ECs are not necessarily uniform w.r.t. top/bottom loading. SMSC ECs which are currently popular in laptops and netbooks (i saw a few when running superiotool on a bunch of machines @ Fry's a few weeks ago ;-) load from the top.
Perhaps with the new partial write logic, along with reading of the ROM prior to doing any write operations, we can tell if the region specified for write via a layout file will exceed the capacity of the chip. If the region the user specifies is within the capacity of the chip, then Flashrom probably should not care what the overall size of the image is.
-
Carl-Daniel Hailfinger -
David Hendricks -
Richard A. Smith -
Richard Smith