Hi,
[fullquote for flashrom@flashrom.org]
On 23.03.2010 22:58, RayeR wrote:
That is very strange. Do you have a log? SB600 should work fine. Maybe the SPI chip is not attached to the SB600 but instead to the SuperI/O. Can you try flashrom -p it87spi
Yes here's it:
C:\F>flashrom.exe -p it87spi flashrom v0.9.1-r933 Error: Programmer initialization failed.
OK, so it is not ITE IT87.
C:\F>flashrom.exe -V -r flashrom v0.9.1-r933 No coreboot table found. DMI string system-manufacturer: "Dell Inc. " DMI string system-product-name: "OptiPlex 320 " DMI string system-version: "Not Specified" DMI string baseboard-manufacturer: "Dell Inc. " DMI string baseboard-product-name: "0CU395" DMI string baseboard-version: " " DMI string chassis-type: "Tower" Found chipset "AMD SB600", enabling flash write... SPI base address is at 0xd8000 Error accessing SB600 SPI registers, 0x1000 bytes at 0x000d8000 dpmi mmap failed: No such file or directory (ENOENT)
Ah yes. That's a limitation of the DOS port of flashrom. Usually the SB600 SPI base address is near the top of the address space (4 GB). On your board it is below 1 MB, and AFAIK Rudolf said that we can't map any region below 1 MB as uncached due to CWSDPMI/DJGPP limitations.
If anyone has an idea how to overcome these limitations, we can fix flashrom for this special case.
See PCI device listing attached.
The W25x40 supports multiple erase commands, and your chipset does not allow flashrom to use the spi_block_erase_20 command. Flashrom notices that this command failed and tries another erase command which works.
OK
Yes, strange. Maybe that happens as side effect from DJGPP compilation?
I don't know...
It should try only 2 times. If it tries more often, we have to check the code (bug?). I think Rudolf(?) said that there are problems if we try to run a CWSDPMI app (dmidecode) from another CWSDPMI app (flashrom). Does it work if dmidecode.exe is in the PATH? Hm. DMIDECODE.EXE is a name with 9+3 letters. That can't work on old
DOS.
Yes it works with dmidecode in path but nobody told me that I need it. On my home PC I already have dmidecode for DOS in my utilities directory. The file name is not problem because of DJGPP is smart and do some file name translation. If there's no LFN support it tries to look for "dmidecod.exe" and when run on LFN enabled OS it will use "dmidecode.exe". But it's different LFN truncating mode than windows use ("dmidec~1.exe"). I don't know why but e.g. DJGPP PKUNZIP tool use filename truncate this way without ~. But it would be better to check if both version of name exist and display non-confusing error message when nothing found.
Michael? Is there a good way to handle this?
Regards, Carl-Daniel