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