Hi.
Patch[] already old. Try this patch.
2008/3/18, malatesh kamatad malateshkamat@gmail.com:
Hi .....
We are working on Coreboot we are trying to flash on thePM49fl004/SST49lf004B
but the flashrom has problems with the write and erase operation. We have MSI Neo and MSI K9N Ultra mother boards with socketed bios. So we are following the procedure what you have given in themailing list (patch) ,
After compiling we are getting the error as bellow[malatesh@turtle22 flashrom]$ make
Checking for pciutils and zlib... found. gcc -o flashrom chipset_enable.o board_enable.o udelay.o jedec.o sst28sf040.o am29f040b.o mx29f002.o sst39sf020.o m29f400bt.o w49f002u.o 82802ab.o msys_doc.o pm49fl004.o sst49lf040.o sst49lfxxxc.o sst_fwhub.o layout.o cbtable.o flashchips.o flashrom.o sharplhf00l04.o w29ee011.o spi.o -lpci -lz -static sst_fwhub.o: In function `probe_sst_fwhub': sst_fwhub.c:(.text+0x21a): undefined reference to `probe_49fl00x' flashchips.o:(.data+0x644): undefined reference to `probe_49fl00x' flashchips.o:(.data+0x648): undefined reference to `erase_49fl00x' flashchips.o:(.data+0x64c): undefined reference to `write_49fl00x' flashchips.o:(.data+0x670): undefined reference to `probe_49fl00x' flashchips.o:(.data+0x674): undefined reference to `erase_49fl00x' flashchips.o:(.data+0x678): undefined reference to `write_49fl00x' collect2: ld returned 1 exit status make: *** [flashrom] Error 1
I think we have down a mistake in this step , we are unable to understand the step i.e diff -Nru flashrom/flash.h flashrom-pm49fl00x/flash.h --- flashrom/flash.h 2008-02-07 03:07:58.000000000 +0500 +++ flashrom-pm49fl00x/flash.h 2008-03-11 13:38:25.000000000+0500
@@ -373,9 +373,9 @@ please guide us............. with regards , Malatesh.
On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
Patch[] already old. Try this patch.
Here's an updated version.
//Peter
Peter Stuge wrote:
On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
Patch[] already old. Try this patch.
Here's an updated version.
//Peter
Acked-by: Bari Ari bari@onelabs.com
On Fri, May 16, 2008 at 08:08:16PM -0500, bari wrote:
Peter Stuge wrote:
On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
Patch[] already old. Try this patch.
Here's an updated version.
Acked-by: Bari Ari bari@onelabs.com
Thanks!! r3332
//Peter
Peter Stuge wrote:
On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
Patch[] already old. Try this patch.
Here's an updated version.
//Peter
Instead of locking the chip, should we put it back to the state it was before? Does this make sense?
On Sat, May 17, 2008 at 03:12:05AM +0200, Stefan Reinauer wrote:
Instead of locking the chip, should we put it back to the state it was before? Does this make sense?
Good question. Actually I don't see why it would matter at all, what matters is to unlock in order to erase or write.
I don't think any other part of flashrom bit twiddling does restore, I'm not sure it actually matters anywhere?
I guess our policy is to leave bits unlocked. I'll read up on the PMC chips and send a patch to remove the locking if it doesn't seem to be harmful.
//Peter
On Sat, May 17, 2008 at 03:22:24AM +0200, Peter Stuge wrote:
I guess our policy is to leave bits unlocked. I'll read up on the PMC chips and send a patch to remove the locking if it doesn't seem to be harmful.
Patch attached, but I sort-of feel like reverting 3332 and instead making two new patches, with this change included in one.
Maybe we should rethink it a little and introduce a chip unlock function that can fail? (Unlocking can fail on the PMC chips and then they will not be writable until after reset. This exists in the ICH SPI master and some SPI chips too.)
//Peter
Peter Stuge wrote:
On Sat, May 17, 2008 at 03:12:05AM +0200, Stefan Reinauer wrote:
Instead of locking the chip, should we put it back to the state it was before? Does this make sense?
Good question. Actually I don't see why it would matter at all, what matters is to unlock in order to erase or write.
I don't think any other part of flashrom bit twiddling does restore,
Yes. They all leave it open, as they do with the board enable and the chipset enable. This is a very high security risk.
I'm not sure it actually matters anywhere?
Well, "It's broken everywhere else"... I figured it matters to some extend, as you put the locking back in place. If you were inspired by the other chips, you would have let the protection open ;-)
I guess our policy is to leave bits unlocked.
Not a policy. If we want a policy, it can not be anything but "We leave the same way as we came"
Stefan
On Sat, May 17, 2008 at 01:51:32PM +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
I don't think any other part of flashrom bit twiddling does restore,
Yes. They all leave it open, as they do with the board enable and the chipset enable. This is a very high security risk.
Why do you think so?
If flashrom was able to unlock something, then another process with sufficient credentials will also be able to unlock that something.
I'm not sure it actually matters anywhere?
Well, "It's broken everywhere else"...
Yes, if not locking == broken, but I'm not sure about that.
I figured it matters to some extend, as you put the locking back in place. If you were inspired by the other chips, you would have let the protection open ;-)
I didn't do much, this patch was written by Nikolay and Reinder, I just reformatted it to HEAD and added the test flags.
I guess our policy is to leave bits unlocked.
Not a policy. If we want a policy, it can not be anything but "We leave the same way as we came"
I seem to recall that there was discussion about restoring the board enable/chipset enable signals too. Someone mentioned that it wasn't always possible or safe to restore signals. I am not sure what the technical motivation for that was. I guess this is what has left the code in limbo..
//Peter
Peter Stuge wrote:
I don't think any other part of flashrom bit twiddling does restore,
Yes. They all leave it open, as they do with the board enable and the chipset enable. This is a very high security risk.
Why do you think so?
If flashrom was able to unlock something, then another process with sufficient credentials will also be able to unlock that something.
If it knows how to do that, and if it intends to do that. If a process just goes berserk and for some reason writes the wrong sequence to some area in memory you might end up with an erased chip.
I don't buy in the argument that tossing the security to the OS or every single process just because the flash safety mechanism can somehow be circumvented is the way to go. You don't leave your root password open, just because someone could reboot the machine and come up with init=/bin/bash.
I'm not sure it actually matters anywhere?
Well, "It's broken everywhere else"...
Yes, if not locking == broken, but I'm not sure about that.
In my opinion, changing the system state is, though.
I seem to recall that there was discussion about restoring the board enable/chipset enable signals too. Someone mentioned that it wasn't always possible or safe to restore signals. I am not sure what the technical motivation for that was.
This is an urban legend. I restored the system state in my initial flash tool attempt /dev/bios on many chipsets. Sure. It takes quite some understanding about what IO areas you write to. But sure setting the system back to the state it was in before can not be more "unsafe" than leaving it in some "undefined" state (And the state is undefined for the rest of the system, that did not know we are running flashrom)
Stefan
On 17.05.2008 14:35, Peter Stuge wrote:
On Sat, May 17, 2008 at 01:51:32PM +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
I don't think any other part of flashrom bit twiddling does restore,
Yes. They all leave it open, as they do with the board enable and the chipset enable. This is a very high security risk.
Why do you think so?
If flashrom was able to unlock something, then another process with sufficient credentials will also be able to unlock that something.
Indeed.
I seem to recall that there was discussion about restoring the board enable/chipset enable signals too. Someone mentioned that it wasn't always possible or safe to restore signals. I am not sure what the technical motivation for that was. I guess this is what has left the code in limbo..
Allow me to clarify. In the past, we restored the memory which was written to during the flash chip probe sequence. That has proven to be harmful, especially because the restored values sometimes did constitute a valid command sequence for some flash chips. Since flash chips are supposed to be ROM, a restore is only needed/possible if the flash chip is shadowed by memory and in that case we can't probe for it anyway. So any restore of the memory location contents touched during chip probe is dangerous and pointless.
Restoring the state of the chipset and the lockbits of a chip is not dangerous (unless a restore has unwanted side effects which would be triggered by touching the register in the first place as well) and could even be argued to constitute good style.
Regards, Carl-Daniel
-
bari -
Carl-Daniel Hailfinger -
Nikolay Petukhov -
Peter Stuge -
Stefan Reinauer