I'm trying to get Flashrom to flash a legacy BIOS image to the RD1 slot on a BIOS Savior PMC4 (thanks Eksidtata!), but I must be missing something...
* I got flashrom checked out, compiled, and make installed. * I show that both the W39V040B (ORG) and Pm49FL004 (RD1) are supported * I've tested that a loose PMC Pm49FL004 is compatible with my mainboard * I've tried issuing a flashrom line three or four times in sequence
However, I cannot get a successful write. Any suggestions? Excerpt follows.
-dhbarr.
dhbarr@ms7260:~/msi_orig$ sudo flashrom -vV -c Pm49FL004 A7260NMS.300 Calibrating delay loop... Setting up microsecond timing loop 401M loops per second ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK Trying Pm49FL004, 512 KB probe_jedec: id1 0x9d, id2 0x6e Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash address: 0x00015f58 - FAILED
On Sun, Mar 18, 2007 at 08:54:29PM -0500, David H. Barr wrote:
dhbarr@ms7260:~/msi_orig$ sudo flashrom -vV -c Pm49FL004 A7260NMS.300
Try -w
//Peter
On 3/18/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sun, Mar 18, 2007 at 08:54:29PM -0500, David H. Barr wrote:
dhbarr@ms7260:~/msi_orig$ sudo flashrom -vV -c Pm49FL004 A7260NMS.300
Try -w
Well -MY- face is red; I forced the chip detection but failed explicitly to invoke the write. Looking back, someone else had this trouble only two weeks ago [1]; obviously I didn't thoroughly do my research.
In any case, I tried with the -w switch and obtained similar results to Adam Kaufman's [2] until my verify failed at 0x000164d0. I also tried Stefan Reinauer's checklist [3], but again verification failed at the same location with the switch in the RD1 position. With the switch in the ORG position, verification succeeded.
Just for grins, I erased the chip then performed a verify against the image I first tried to flash. This also failed, again at 0x000164d0. It seems as though none of my commands actually -wrote- anything.
Full details after footnotes; you may notice I used the v130 in these test cases; that is the factory default firmware shipped with my board.
-dhbarr.
1. "Flashrom problem & IRQ questions" http://linuxbios.org/pipermail/linuxbios/2007-March/018671.html
2. "LinuxBIOS Solaris Dev" http://linuxbios.org/pipermail/linuxbios/2007-February/018172.html
3. "cant detect bios with flash software" http://linuxbios.org/pipermail/linuxbios/2006-June/014914.html
-=[Results Similar to A.K.]=- $ flashrom -vV -c Pm49FL004 -w A7260NMS.130 Calibrating delay loop... Setting up microsecond timing loop 402M loops per second ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK Trying Pm49FL004, 512 KB probe_jedec: id1 0x9d, id2 0x6e Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 0007 at address: 0x00070000 Verifying flash address: 0x000164d0 - FAILED
-=[SR's Checklist]=-
$ flashrom -r A7260NMS.org Calibrating delay loop... ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK W39V040B found at physical address: 0xfff80000 Flash part is W39V040B (512 KB) Reading Flash...done
$ flashrom -w A7260NMS.org Calibrating delay loop... ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 0007 at address: 0x00070000
$ flashrom -vV A7260NMS.org Calibrating delay loop... Setting up microsecond timing loop 402M loops per second ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK <snip> Trying Pm49FL004, 512 KB probe_jedec: id1 0x9d, id2 0x6e Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash address: 0x000164d0 - FAILED
-=[Erase then Verify]=-
$ flashrom -E Calibrating delay loop... ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Erasing flash chip
$ flashrom -V -v A7260NMS.130 -c Pm49FL004 Calibrating delay loop... Setting up microsecond timing loop 401M loops per second ok No LinuxBIOS table found. Enabling flash write on NVIDIA MCP55...OK Trying Pm49FL004, 512 KB probe_jedec: id1 0x9d, id2 0x6e Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash address: 0x000164d0 - FAILED
* David H. Barr dhbarr@gozelle.com [070320 03:36]:
In any case, I tried with the -w switch and obtained similar results to Adam Kaufman's [2] until my verify failed at 0x000164d0. I also tried Stefan Reinauer's checklist [3], but again verification failed at the same location with the switch in the RD1 position. With the switch in the ORG position, verification succeeded.
Just for grins, I erased the chip then performed a verify against the image I first tried to flash. This also failed, again at 0x000164d0. It seems as though none of my commands actually -wrote- anything.
So the original image is 0xff in the first 164d0 bytes? Or did you brick the machine this way?
On 3/20/07, Stefan Reinauer stepan@coresystems.de wrote:
So the original image is 0xff in the first 164d0 bytes? Or did you brick the machine this way?
Yes, it appears that for v130 it is 0xff in the first 164d0 bytes. Looking at v300, it is 0xff in the first 15f58, and trying with other factory BIOS images yeilds similar results (0xff in the first N bytes).
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
I have two of these boards to work with, however, so I'm not averse to bricking one as I can always hotswap.
-dhbarr.
On 3/20/07, David H. Barr dhbarr@gozelle.com wrote:
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
Long story short, flashrom -w is a no-go for this board (MSI K9N Neo f / ms7260). Tried in both ORG and RD1 modes with BIOS Savior PMC4, and with the following loose flash parts:
PMC Pm49FL004 Winbond W39V040B
-r and -E flags both worked a treat; verified this by issuing an erase, then a -r to file, then a -vV against the resulting file. It was the only time I ever saw a "Verifying flash - VERIFIED" message.
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
-dhbarr.
On 21.03.2007 01:53, David H. Barr wrote:
On 3/20/07, David H. Barr dhbarr@gozelle.com wrote:
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
Long story short, flashrom -w is a no-go for this board (MSI K9N Neo f / ms7260).
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
Does AMIFLH.exe work in dosemu or some other environment where it can be aborted while flashing so we can find out if an aborted AMIFLH is enough for flashrom -w to work?
Regards, Carl-Daniel
On 3/21/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 21.03.2007 01:53, David H. Barr wrote:
On 3/20/07, David H. Barr dhbarr@gozelle.com wrote:
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
Long story short, flashrom -w is a no-go for this board (MSI K9N Neo f / ms7260).
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
Does AMIFLH.exe work in dosemu or some other environment where it can be aborted while flashing so we can find out if an aborted AMIFLH is enough for flashrom -w to work?
A few unsorted thoughts:
- the correct name of this tool is AFUDOS; AMIFLH is a vendor re-badge - the same type of utility from Award / Phoenix is AWDFLASH - MSI uses both AWD and AMI BIOS images, so the "mojo" may be present in both utilities (a generic enable sequence? a list of enable sequences?) - as you mention, what about aborts / interrupts - what about a binary patch against one of these tools to "force" a write - along that same line, what about disabling one or more section of these tools to end up with a simple "enabler", or a brute force writer, or ??? - my hunch tells me the AWDFLASH util is more logical, and therefore easier to toy with; AFUDOS appears to be built on top of another tool
I'll try some follow-up with various dos-type environments to see if that particular avenue of investigation takes me anywhere. I'd be happy with any clearly legal solution that can be a) reliably reproduced, b) documented, and c) automated.
-dhb.
David H. Barr wrote:
On 3/21/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 21.03.2007 01:53, David H. Barr wrote:
On 3/20/07, David H. Barr dhbarr@gozelle.com wrote:
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
Long story short, flashrom -w is a no-go for this board (MSI K9N Neo f / ms7260).
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
Does AMIFLH.exe work in dosemu or some other environment where it can be aborted while flashing so we can find out if an aborted AMIFLH is enough for flashrom -w to work?
A few unsorted thoughts:
- the correct name of this tool is AFUDOS; AMIFLH is a vendor re-badge
- the same type of utility from Award / Phoenix is AWDFLASH
- MSI uses both AWD and AMI BIOS images, so the "mojo" may be present in both utilities (a generic enable sequence? a list of enable sequences?)
- as you mention, what about aborts / interrupts
- what about a binary patch against one of these tools to "force" a write
- along that same line, what about disabling one or more section of these tools to end up with a simple "enabler", or a brute force writer, or ???
- my hunch tells me the AWDFLASH util is more logical, and therefore easier to toy with; AFUDOS appears to be built on top of another tool
I'll try some follow-up with various dos-type environments to see if that particular avenue of investigation takes me anywhere. I'd be happy with any clearly legal solution that can be a) reliably reproduced, b) documented, and c) automated.
-dhb.
Probably a stupid question, but why don't we just ask the uniflash developer how he figured it out? He's got support for several different boards with special locking mechanisms.
-Corey
On Wed, Mar 21, 2007 at 11:43:00PM -0400, Corey Osgood wrote:
Probably a stupid question,
Not at all.
but why don't we just ask the uniflash developer how he figured it out? He's got support for several different boards with special locking mechanisms.
Sometimes the factory BIOS has special callbacks to enable flash writing.
We could just re-implement the uniflash drivers missing from flashrom that don't use such callbacks, but noone has started yet.
//Peter
Quoting Corey Osgood corey_osgood@verizon.net:
David H. Barr wrote:
On 3/21/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 21.03.2007 01:53, David H. Barr wrote:
On 3/20/07, David H. Barr dhbarr@gozelle.com wrote:
I have not yet issued a write in the ORG position, only read and verify. I erased the Pm49FL004 flash part present in the BIOS Savior, not the onboard W39V040B.
Long story short, flashrom -w is a no-go for this board (MSI K9N Neo f / ms7260).
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
Does AMIFLH.exe work in dosemu or some other environment where it can be aborted while flashing so we can find out if an aborted AMIFLH is enough for flashrom -w to work?
A few unsorted thoughts:
- the correct name of this tool is AFUDOS; AMIFLH is a vendor re-badge
- the same type of utility from Award / Phoenix is AWDFLASH
- MSI uses both AWD and AMI BIOS images, so the "mojo" may be present in both utilities (a generic enable sequence? a list of enable
sequences?)
- as you mention, what about aborts / interrupts
- what about a binary patch against one of these tools to "force" a write
- along that same line, what about disabling one or more section of these tools to end up with a simple "enabler", or a brute force writer, or ???
- my hunch tells me the AWDFLASH util is more logical, and therefore easier to toy with; AFUDOS appears to be built on top of another tool
I'll try some follow-up with various dos-type environments to see if that particular avenue of investigation takes me anywhere. I'd be happy with any clearly legal solution that can be a) reliably reproduced, b) documented, and c) automated.
-dhb.
Probably a stupid question, but why don't we just ask the uniflash developer how he figured it out? He's got support for several different boards with special locking mechanisms.
-Corey
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
I ack that Corey, I think uniflash is much more powerful than any of the vender provided dos flashing tools available!
Thanks - Joe
* joe@smittys.pointclark.net joe@smittys.pointclark.net [070322 05:53]:
Probably a stupid question, but why don't we just ask the uniflash developer how he figured it out? He's got support for several different boards with special locking mechanisms.
I ack that Corey, I think uniflash is much more powerful than any of the vender provided dos flashing tools available!
No need to ask. The code is freely available and rather simple. The reason flashrom does not do it is that the mechanism incorporates calling 16bit code. Nothing too magic. It will just never work with AMD64 64bit kernels.
You might also require to specify an Award BIOS image to make the AWDFLASH way work.
* David H. Barr dhbarr@gozelle.com [070322 04:21]:
- the same type of utility from Award / Phoenix is AWDFLASH
- MSI uses both AWD and AMI BIOS images, so the "mojo" may be present in both utilities (a generic enable sequence? a list of enable sequences?)
Award BIOS uses an in-flash structure starting with the magic "AWDFLASH". It contains a couple of pointers to 16bit functions for enabling/disabling shadowing and flash write protection.
AMI BIOS uses an intXX call for that. Refer to RBIL for more information.
So none of the dos tools knows about this itself. It just asks the bios (image file) to show the system bios.
The sequence to call these in-flash enablers is well-known. Uniflash is using them and so knows how to flash every board without the need for new code, as long as it knows the flash chips.
- along that same line, what about disabling one or more section of these tools to end up with a simple "enabler", or a brute force writer, or ???
I am not exactly convinced that this is legal. esreveR gnireenigne is, in a couple of countries though
Stefan
On 22.03.2007 10:56, Stefan Reinauer wrote:
The sequence to call these in-flash enablers is well-known. Uniflash is using them and so knows how to flash every board without the need for new code, as long as it knows the flash chips.
Does Uniflash work on this board? If so, you can modify it to print out the addresses it would be calling (along with the parameters) and then call these addresses in vm86 under Linux. That should work. You can even dump the PCI config space before and after enabling and diff them.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070322 14:22]:
On 22.03.2007 10:56, Stefan Reinauer wrote:
The sequence to call these in-flash enablers is well-known. Uniflash is using them and so knows how to flash every board without the need for new code, as long as it knows the flash chips.
Does Uniflash work on this board? If so, you can modify it to print out the addresses it would be calling (along with the parameters) and then call these addresses in vm86 under Linux. That should work. You can even dump the PCI config space before and after enabling and diff them.
Comparing registers is a good approach. You might have to dump the registers of your superio as well, though, not only the pci config space, as bios write protect is usually done with superio GPIOs.
I just looked at uniflash. One possibility would be to implement AMIBIOS.PAS by using vm86 or, better because it works in the BSDs as well, lrmi-0.10, the linux realmode interface wrapper.
I found out uniflash supports AMI, but not award. From the time when I developed /dev/bios, I found this note in a stack of old paper that I thought I'd never need anymore:
This is a structure found in every award bios image (the friend who found this out told me it is legally absolutely unproblematic since it just means using a callback structure made for interoperability. Before you do anything with this (including calling into those offsets), be sure that your local law permits this. As far as I understand, the DMCA is about circumventing copy protection, not overwrite protection. But I am not a lawyer, so better don't quote me on that.
8 bytes: AWDFLASH 2 bytes: ?? 2 bytes: offset of bios write enable function 2 bytes: offset of bios write disable function 2 bytes: ?? 2 bytes: ?? 2 bytes: offset of bios shadow disable function 2 bytes: offset of bios shadow enable function
Best regards, Stefan
* Stefan Reinauer stepan@openbios.org [070322 15:08]:
This is a structure found in every award bios image
A similar structure is found in ASUS branden bioses. Look at ASUSBIOS.PAS in uniflash
Stefan
On Thu, 22 Mar 2007 15:16:42 +0100 Stefan Reinauer stepan@coresystems.de wrote:
- Stefan Reinauer stepan@openbios.org [070322 15:08]:
This is a structure found in every award bios image
A similar structure is found in ASUS branden bioses. Look at ASUSBIOS.PAS in uniflash
Feature of which could be possibly incorporated into flashrom, in order not to have stuck system while detecting flash-chip (on ASUS boards).
* Anton anton.borisov@gmail.com [070322 15:22]:
On Thu, 22 Mar 2007 15:16:42 +0100 Stefan Reinauer stepan@coresystems.de wrote:
- Stefan Reinauer stepan@openbios.org [070322 15:08]:
This is a structure found in every award bios image
A similar structure is found in ASUS branden bioses. Look at ASUSBIOS.PAS in uniflash
Feature of which could be possibly incorporated into flashrom, in order not to have stuck system while detecting flash-chip (on ASUS boards).
Yes. This should work. The one disadvantage is that it stops working as soon as you flashed linuxbios for the first time, because it does not provide that information.
(Maybe it should, btw, when we want to save configuration stuff in a flash block?)
On 22.03.2007 15:24, Stefan Reinauer wrote:
- Anton anton.borisov@gmail.com [070322 15:22]:
On Thu, 22 Mar 2007 15:16:42 +0100 Stefan Reinauer stepan@coresystems.de wrote:
- Stefan Reinauer stepan@openbios.org [070322 15:08]:
This is a structure found in every award bios image
A similar structure is found in ASUS branden bioses. Look at ASUSBIOS.PAS in uniflash
Feature of which could be possibly incorporated into flashrom, in order not to have stuck system while detecting flash-chip (on ASUS boards).
Yes. This should work. The one disadvantage is that it stops working as soon as you flashed linuxbios for the first time, because it does not provide that information.
(Maybe it should, btw, when we want to save configuration stuff in a flash block?)
Why not use an extra utility for this (detect_flash_enable_strategy)?
# ./detect_flash_enable_strategy Performing PCI and SuperIO config space dump 1... Calling Flash enable hooks in proprietary BIOS.... Performing PCI and SuperIO config space dump 2... Diffing dumps... PCI config space byte 0x13 of device 00:1e.0 changed from 0x20 to 0x30 Please mail the above information with lspci -nv and a description of your mainboard to linuxbios@linuxbios.org.
What do you think?
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070322 15:35]:
Why not use an extra utility for this (detect_flash_enable_strategy)?
# ./detect_flash_enable_strategy Performing PCI and SuperIO config space dump 1... Calling Flash enable hooks in proprietary BIOS.... Performing PCI and SuperIO config space dump 2... Diffing dumps... PCI config space byte 0x13 of device 00:1e.0 changed from 0x20 to 0x30 Please mail the above information with lspci -nv and a description of your mainboard to linuxbios@linuxbios.org.
What do you think?
Great idea. This could even be a shell script utilizing dump_superio and lspci. (heh, should dump_superio be called lspnp?)
Stefan
On Tue, Mar 20, 2007 at 07:53:08PM -0500, David H. Barr wrote:
Anyhoo, chalk another board on the "needs vendor mojo to enable writes" list. For the record, the vendor-supplied utility is "AMIFlh.exe" from AMIBIOS.
Perhaps a good GSoC project would be to create an environment where we could observe what a given vendor flash utility really does?
//Peter
-
Anton -
Carl-Daniel Hailfinger -
Corey Osgood -
David H. Barr -
joe＠smittys.pointclark.net -
Peter Stuge -
Stefan Reinauer -
Stefan Reinauer