Hi,
So I took a huge leap of faith, and used flashrom to update my bios. My motherboard is gigabyte GA-G33-DS3R, lspci attached.
I used:
flashrom -c MX25L8005 -w g33ds3r.f7h
as it had that chip (1024K) and another unknown one (0K).
It took around 1 minute.
btw, that worked on linux 2.6.24.7, but on linux 2.6.26 (which I need for other device support), I get:
# flashrom -r bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... Can't mmap memory using /dev/mem: Invalid argument
linux 2.6.26 has an option for filtering userspace access to /dev/mem, I tried both on and off but that didn't fix it.
Regards, Laurence
Hi Laurence,
On 20.07.2008 01:54, Laurence Darby wrote:
So I took a huge leap of faith, and used flashrom to update my bios. My motherboard is gigabyte GA-G33-DS3R, lspci attached.
I used:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS. If you haven't tried rebooting yet, I'd advise caution. Please try to verify the image you just wrote before rebooting.
as it had that chip (1024K) and another unknown one (0K).
Yes, known quirk, will be fixed in the near future.
It took around 1 minute.
btw, that worked on linux 2.6.24.7, but on linux 2.6.26 (which I need for other device support), I get:
# flashrom -r bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... Can't mmap memory using /dev/mem: Invalid argument
linux 2.6.26 has an option for filtering userspace access to /dev/mem, I tried both on and off but that didn't fix it.
Ouch. That would be a regression in Linux. Have you tried to report this to the linux-kernel mailing list?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS.
The ichspi driver erases a block prior to writing it, as all the non-spi drivers do. The only behavior that would possibly make sense from a user perspective.
Stefan
Hi Carl,
Carl-Daniel Hailfinger wrote:
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS. If you haven't tried rebooting yet, I'd advise caution. Please try to verify the image you just wrote before rebooting.
Ho hum.. Well I had extracted the initial bios and compared that with the same version I downloaded off the website, I found the first 512K matched md5sums, then there were differences in the second half, and using 'strings', it was just config changes and a record of the motherboard & cpu it booted on. So, reading it worked reliably, and for writting, I thought the only thing that could go wrong is a power cut (yes I should have UPS). After the write completed without hicup, I rebooted.
I don't really see how there could be a mixture of versions, shouldn't one have just cleanly overwritten the other with the file contents?
Found chipset "Intel ICH9R", enabling flash write... Can't mmap memory using /dev/mem: Invalid argument
linux 2.6.26 has an option for filtering userspace access to /dev/mem, I tried both on and off but that didn't fix it.
Ouch. That would be a regression in Linux. Have you tried to report this to the linux-kernel mailing list?
No, sorry. SEP :)
Laurence
On 20.07.2008 02:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS.
The ichspi driver erases a block prior to writing it, as all the non-spi drivers do. The only behavior that would possibly make sense from a user perspective.
Ah yes. I forgot about the silent data corruption bug in the ICH SPI driver. It works most of the time, but there are quite a few chips listed in flashchips.c which will act weird or require a separate erase call. Besides that, the block erase code does not belong in the chipset driver, it belongs in the flash chip driver.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 20.07.2008 02:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS.
The ichspi driver erases a block prior to writing it, as all the non-spi drivers do. The only behavior that would possibly make sense from a user perspective.
Ah yes. I forgot about the silent data corruption bug in the ICH SPI driver. It works most of the time, but there are quite a few chips listed in flashchips.c which will act weird or require a separate erase call.
In fact, my experience was the other way around. The seperate erase command does not work for most of the chips in the list on ICH7.
What ICH did you make this experience on?
Besides that, the block erase code does not belong in the chipset driver, it belongs in the flash chip driver.
I guess you are right. Patches, someone?
On 20.07.2008 13:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 20.07.2008 02:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS.
The ichspi driver erases a block prior to writing it, as all the non-spi drivers do. The only behavior that would possibly make sense from a user perspective.
Ah yes. I forgot about the silent data corruption bug in the ICH SPI driver. It works most of the time, but there are quite a few chips listed in flashchips.c which will act weird or require a separate erase call.
In fact, my experience was the other way around. The seperate erase command does not work for most of the chips in the list on ICH7.
That's expected. I looked at spi.c and it seems that only one chip erase command has a corresponding function. The other one is missing completely. IIRC I had it once in my code, but it may have disappeared either during initial checkin or later. Basically, the chip erase function for some families of SPI chips in flashchips.c is wrong, it should be spi_chip_erase_60 instead of spi_chip_erase_c7.
What ICH did you make this experience on?
That is purely from reading the datasheets.
Besides that, the block erase code does not belong in the chipset driver, it belongs in the flash chip driver.
I guess you are right. Patches, someone?
ich_spi_erase_block should be a generic SPI routine and choose the correct block erase command per chip. JEDEC_BE_D8 is not supported by all SPI chips.
I can try to prepare patches over the next week. What do you think about changing the generic erase and write function prototypes to accept ranges and move the call to autoerase functions into the main flashrom.c function?
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Laurence Darby -
Stefan Reinauer