On Fri, Jun 13, 2008 at 02:30:31PM -0700, Victor Zele wrote:
bash-3.00# ./flashrom -vw sa6k14.rom
..
coreboot last image size (not ROM size) is -1791885312 bytes. Segmentation fault
Victor used the factory flashing utility to update his factory BIOS, then he read back the sa6k14.rom file using flashrom.
When trying to write sa6k14.rom, flashrom mistakes it for a coreboot image and crashes because it is in fact not a coreboot image, and where coreboot stores hints for flashrom, sa6k14.rom has data which is garbage to flashrom.
The problem lies in layout.c:show_id() which does this to identify a factory BIOS:
--8<-- walk = (unsigned int *)(bios + size - 0x10); walk--;
if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) { /* We might have an Nvidia chipset bios * which stores the id information at a * different location. */ walk = (unsigned int *)(bios + size - 0x80); walk--; }
if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) { printf("Flash image seems to be a legacy BIOS. mainboard_vendor = def_name; mainboard_part = def_name; return 0; } -->8--
Seems that the 4 last bytes before the reset vector are checked, and that flashrom considers the image to be coreboot when bits 9-0 are 0 and one or more of bits 31-10 are 1.
This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature?
//Peter
Peter Stuge wrote:
Seems that the 4 last bytes before the reset vector are checked, and that flashrom considers the image to be coreboot when bits 9-0 are 0 and one or more of bits 31-10 are 1.
This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature?
Yes. A LAR file with that information in the image.
On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature?
Yes. A LAR file with that information in the image.
Ah of course - yes for v3 that's perfect.
What about v2?
//Peter
Peter Stuge wrote:
On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature?
Yes. A LAR file with that information in the image.
Ah of course - yes for v3 that's perfect.
What about v2?
I suggest using the same mechanism, wrapping the information in a lar header, making it a single file lar. The lar format can handle this, and we don't have to worry for different versions.
On 14.06.2008 21:53, Stefan Reinauer wrote:
Peter Stuge wrote:
On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature?
Yes. A LAR file with that information in the image.
Ah of course - yes for v3 that's perfect.
What about v2?
I suggest using the same mechanism, wrapping the information in a lar header, making it a single file lar. The lar format can handle this, and we don't have to worry for different versions.
How about a generic bootblock/VPD signature instead? Having a short signature in the top 256 bytes or so will allow recognition of complete and incomplete (only partly mapped) coreboot images easily.
Proposal for signature formats:
4 bytes: "CB20" for v2.0 and "CB30" for v3.0
8 bytes (option 1): "CB203300" for v2.0, rev 3300
8 bytes (option 2): "coreboot"
16 bytes: "coreboot20r3300 " for v2.0, r3300 (note the space at the end for 5-digit svn revisions)
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 14.06.2008 21:53, Stefan Reinauer wrote:
I suggest using the same mechanism, wrapping the information in a lar header, making it a single file lar. The lar format can handle this, and we don't have to worry for different versions.
How about a generic bootblock/VPD signature instead? Having a short signature in the top 256 bytes or so will allow recognition of complete and incomplete (only partly mapped) coreboot images easily.
Proposal for signature formats:
4 bytes: "CB20" for v2.0 and "CB30" for v3.0
8 bytes (option 1): "CB203300" for v2.0, rev 3300
8 bytes (option 2): "coreboot"
16 bytes: "coreboot20r3300 " for v2.0, r3300 (note the space at the end for 5-digit svn revisions)
Top 256 bytes will not always work. The current trouble is due to the fact that we have some mainboards that need the information in a different place than others.
Other than that, we might indeed put the coreboot version into the firmware signature, too, if there's a reason to do so. Is there?
I miss the actual information in your suggestion, namely the mainboard vendor and type.
Since we already have LAR, using that format instead of yet another signature rule makes a lot of sense in my opinion.
Stefan
On 16.06.2008 19:02, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 14.06.2008 21:53, Stefan Reinauer wrote:
I suggest using the same mechanism, wrapping the information in a lar header, making it a single file lar. The lar format can handle this, and we don't have to worry for different versions.
How about a generic bootblock/VPD signature instead? Having a short signature in the top 256 bytes or so will allow recognition of complete and incomplete (only partly mapped) coreboot images easily.
Proposal for signature formats:
4 bytes: "CB20" for v2.0 and "CB30" for v3.0
8 bytes (option 1): "CB203300" for v2.0, rev 3300
8 bytes (option 2): "coreboot"
16 bytes: "coreboot20r3300 " for v2.0, r3300 (note the space at the end for 5-digit svn revisions)
Top 256 bytes will not always work. The current trouble is due to the fact that we have some mainboards that need the information in a different place than others.
Anything in the top 4k would be OK for me, unless there are specific reasons this is impossible with some boards. I'd appreciate a pointer about the "different place" thing.
Other than that, we might indeed put the coreboot version into the firmware signature, too, if there's a reason to do so. Is there?
Not sure about svn revision, but differentiating between v2 and v3 would help. For one, we could keep a pseudo-LAR out of v2.
I miss the actual information in your suggestion, namely the mainboard vendor and type.
Placing vendor and type somewhere else is possible, as long as flashrom knows that it should look there.
Since we already have LAR, using that format instead of yet another signature rule makes a lot of sense in my opinion.
For v3, yes mostly. For v2, someone would have to add a invalid LAR pseudoheader to the final linked image. Definitely not something I'd like to try (my linker script skills are not good enough nor do I consider this to be a particularly compelling idea).
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Top 256 bytes will not always work. The current trouble is due to the fact that we have some mainboards that need the information in a different place than others.
Anything in the top 4k would be OK for me, unless there are specific reasons this is impossible with some boards. I'd appreciate a pointer about the "different place" thing.
Why would you want to artificially limit this at all. A lar entry can be anywhere in the binary and it will still work. Now imagine how flexible that would be ;-)
Other than that, we might indeed put the coreboot version into the firmware signature, too, if there's a reason to do so. Is there?
Not sure about svn revision, but differentiating between v2 and v3 would help. For one, we could keep a pseudo-LAR out of v2.
What's the benefit of using "CB20" as a magic rather than "LARCHIVE"? Exactly: None. There are disadvantages to having to maintain two different ways of doing things though. Especially given that v2 is going to be obsoleted some time.
I miss the actual information in your suggestion, namely the mainboard vendor and type.
Placing vendor and type somewhere else is possible, as long as flashrom knows that it should look there.
Sure. And this is what the whole discussion is about. Maybe you missed the point in the first place?
Since we already have LAR, using that format instead of yet another signature rule makes a lot of sense in my opinion.
For v3, yes mostly. For v2, someone would have to add a invalid LAR pseudoheader to the final linked image.
No invalid header needed. No pseudo header anyways. Just pack a plain normal valid header there.
Definitely not something I'd like to try (my linker script skills are not good enough nor do I consider this to be a particularly compelling idea).
Placing a few bytes at an arbitrary 16byte aligned address within the image is quite simple.
On 16.06.2008 19:53, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Top 256 bytes will not always work. The current trouble is due to the fact that we have some mainboards that need the information in a different place than others.
Anything in the top 4k would be OK for me, unless there are specific reasons this is impossible with some boards. I'd appreciate a pointer about the "different place" thing.
Why would you want to artificially limit this at all. A lar entry can be anywhere in the binary and it will still work. Now imagine how flexible that would be ;-)
And unpacking the lar will possible result in garbage if the header is "somewhere".
Other than that, we might indeed put the coreboot version into the firmware signature, too, if there's a reason to do so. Is there?
Not sure about svn revision, but differentiating between v2 and v3 would help. For one, we could keep a pseudo-LAR out of v2.
What's the benefit of using "CB20" as a magic rather than "LARCHIVE"? Exactly: None. There are disadvantages to having to maintain two different ways of doing things though. Especially given that v2 is going to be obsoleted some time.
I miss the actual information in your suggestion, namely the mainboard vendor and type.
Placing vendor and type somewhere else is possible, as long as flashrom knows that it should look there.
Sure. And this is what the whole discussion is about. Maybe you missed the point in the first place?
The point was to make sure flashrom does not segfault anymore on real world images. Feel free to fix that in any way you want.
Since we already have LAR, using that format instead of yet another signature rule makes a lot of sense in my opinion.
For v3, yes mostly. For v2, someone would have to add a invalid LAR pseudoheader to the final linked image.
No invalid header needed. No pseudo header anyways. Just pack a plain normal valid header there.
And unpacking the plain normal valid header will result in what?
Definitely not something I'd like to try (my linker script skills are not good enough nor do I consider this to be a particularly compelling idea).
Placing a few bytes at an arbitrary 16byte aligned address within the image is quite simple.
Great. As long as you fix the flashrom segfault (which needs a flashrom code change and was the reason the thread got started) you can change the v2 image any way you want. You could even postpone the signature decision and improve the coreboot detection heuristic in flashrom by checking the read values for sanity (a negative image size is not sane).
Regards, Carl-Daniel
P.S. Back to university work...
Carl-Daniel Hailfinger wrote:
And unpacking the lar will possible result in garbage if the header is "somewhere".
Unpacking it? We're talking about searching a signature. Nobody will ever unpack a v2 image with a single lar entry.
Besides, the utility should be able to cope with it. At least per design. Even if it doesn't make sense.
And unpacking the plain normal valid header will result in what?
A file containing your mainboard vendor and type, I suppose?
-
Carl-Daniel Hailfinger -
Peter Stuge -
Stefan Reinauer