Hi Jürgen,
I remember a similar case where flashrom was unable to write, and that board also had a second chipset match. We might have the same issue here: To PCI devices with the same ID, one acts as southbridge and the other one is unused. We might enable the wrong one here and might have to refine detection a bit. OTOH, a flash chip is detected, so we know that write was enabled on the address space mapped to the flash chip (but that write enable might have not been done by flashrom).
Am 26.02.2012 20:38 schrieb Jürgen Trapp:
ubuntu@ubuntu:~/coreboot$ sudo flashrom -VV flashrom v0.9.5.1-r1508 on Linux 3.0.0-12-generic (i686), built with libpci 3.1.7, GCC 4.6.1, little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 4001 usecs, 1093M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 0 us, 10000 myus = 8001 us, 16004 myus = 16001 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "HP xw9300 Workstation" DMI string system-version: " " DMI string baseboard-manufacturer: "Hewlett-Packard" DMI string baseboard-product-name: "09C4h" DMI string baseboard-version: "Not Specified" DMI string chassis-type: "Mini Tower" Found chipset "NVIDIA CK804" with PCI ID 10de:0051. Enabling flash write... OK. WARNING: unexpected second chipset match: "NVIDIA CK804"
Side note: We should print the PCI ID for the second chipset match as well.
ignoring, please report lspci and board URL to flashrom@flashrom.org with 'CHIPSET: your board name' in the subject line. The following protocols are supported: Non-SPI. Probing for AMD Am29F010A/B, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content [...]
Could you run the following command as root and post the results? lspci -nnvvxxx
That should help us determine which one of the CK804 southbridges we should enable.
However, it is possible that we enabled the right southbridge due to pure luck and there is a separate write protection (jumper or solder bridge or something controllable in software). If that is the case, somebody has to find out how to enable writes by reverse engineering or by looking at the docs if the docs are good.
Regards, Carl-Daniel