ichxrom driver question
I attempted to flash the BIOS on a machine with an Intel 82801CA (ICH3-S) I/O Controller Hub as follows:
# modprobe ichxrom
# modprobe mtdchar
# mtd_unlock /dev/mtd0
# mtd_eraseall /dev/mtd0
Erased 512 Kibyte @ 0 -- 100% complete.
# dd if=bios_image of=/dev/mtd0
1024+0 records in
1024+0 records out
# dd if=/dev/mtd0 of=result
1024+0 records in
1024+0 records out
# mtd_lock /dev/mtd0 0 -1After doing the above, I examind the file 'result' and all it contains is a bunch of zero bytes. Thus the BIOS flashing operation appears to have failed (I confirmed this by attempting to reboot, and sure enough, the BIOS appears to have been wiped out).
I did this using the version of the ichxrom driver from the 2.6.9 kernel. Looking briefly at this code in comparison to a more recent version of the code from the 2.6.14.4 kernel, it looks like substantial changes have been made.
So my question is, are there known problems with the version of the ichxrom driver in the 2.6.9 kernel, and if so, have the problems been fixed in later kernels? Also, are there any known issues with the ICH3-S that may explain the behavior I observe? When replying, please cc [email protected].
Thanks,
Dave
Quoted 16 lines · Dave Peterson
I attempted to flash the BIOS on a machine with an Intel 82801CA (ICH3-S) I/O Controller Hub as follows:
# modprobe ichxrom # modprobe mtdchar # mtd_unlock /dev/mtd0 # mtd_eraseall /dev/mtd0 Erased 512 Kibyte @ 0 -- 100% complete. # dd if=bios_image of=/dev/mtd0 1024+0 records in 1024+0 records out # dd if=/dev/mtd0 of=result 1024+0 records in 1024+0 records out # mtd_lock /dev/mtd0 0 -1
Quoted 4 lines
After doing the above, I examind the file 'result' and all it contains is a bunch of zero bytes. Thus the BIOS flashing operation appears to have failed (I confirmed this by attempting to reboot, and sure enough, the BIOS appears to have been wiped out).
Hmm. Immediately after the erase operation you should see all f's.
The only thing I can think of that might trigger what you are seeing is a cached flash chip.
Quoted 4 lines
I did this using the version of the ichxrom driver from the 2.6.9 kernel. Looking briefly at this code in comparison to a more recent version of the code from the 2.6.14.4 kernel, it looks like substantial changes have been made.
I honestly don't recall. I don't have a good handle on when changes were made versus when they were merged.
Quoted 3 lines
So my question is, are there known problems with the version of the ichxrom driver in the 2.6.9 kernel, and if so, have the problems been fixed in later kernels?
The biggest practical changes was to allow it to work with other than intel flash parts. That required removing some hacks. But I don't know of any cases where things half worked.
Quoted 3 lines
Also, are there any known issues with
the ICH3-S that may explain the behavior I observe? When replying, please cc [email protected].
The ICH3-S is more of a conduit. The usual questions are:
Is there motherboard specific magic that denies writes? What is the actual flash chip you are flashing.
Except for the possibility of bad cache I can't think of anything that would cause the wrong data to be written. Are you certain you have a good flash image?
Eric
Quoted 1 line · Eric W. Biederman
Hmm. Immediately after the erase operation you should see all f's.
I tried it a few times. My recollection is that after the first attempt at erasing, the first part of the flash memory contained all f's and the rest contained data that appeared to be the old BIOS. On a subsequent attempt, I saw all zeros, and this is what I still see when I try to flash the BIOS again.
Quoted 2 lines
The only thing I can think of that might trigger what you are seeing is a cached flash chip.
What does "cached flash chip" mean? I have very little familiarity with how these flash chips operate.
Quoted 4 lines
The ICH3-S is more of a conduit. The usual questions are:
Is there motherboard specific magic that denies writes? What is the actual flash chip you are flashing.
How do I determine whether there is motherboard-specific magic? The motherboard is a Supermicro P4DPR-iGM and the flash chip is an Intel 82802AB.
Quoted 3 lines
Except for the possibility of bad cache I can't think of anything that would cause the wrong data to be written. Are you certain you have a good flash image?
The flash image I tried to install was an exact duplicate of the currently installed flash image, obtained as follows:
# dd if=/dev/mtd0 of=bios_image
I was just testing the BIOS flashing mechanism to see if it worked.
Quoted 9 lines · Dave Peterson
Quoted 1 line · Eric W. Biederman
Hmm. Immediately after the erase operation you should see all f's.
I tried it a few times. My recollection is that after the first attempt at erasing, the first part of the flash memory contained all f's and the rest contained data that appeared to be the old BIOS. On a subsequent attempt, I saw all zeros, and this is what I still see when I try to flash the BIOS again.
Quoted 5 lines
Quoted 2 lines
The only thing I can think of that might trigger what you are seeing is a cached flash chip.
What does "cached flash chip" mean? I have very little familiarity with how these flash chips operate.
The flash chips contents being cached in the cpus cache. cat /proc/mtrr and see if covers the 0xfff80000 - 0xffffffff range where your flash chip lives.
Quoted 6 lines
Quoted 4 lines
The ICH3-S is more of a conduit. The usual questions are:
Is there motherboard specific magic that denies writes? What is the actual flash chip you are flashing.
How do I determine whether there is motherboard-specific magic?
Usually I see if I can read out the id on the flash chip. That tests to see if writes make it to the device because you have to write a command.
Quoted 2 lines
The motherboard is a Supermicro P4DPR-iGM and the flash chip is an Intel 82802AB.
Ok. That is one of the configurations I have tested although I haven't gone back and regression tested on one of those boards in a while.
Quoted 10 lines
Quoted 3 lines
Except for the possibility of bad cache I can't think of anything that would cause the wrong data to be written. Are you certain you have a good flash image?
The flash image I tried to install was an exact duplicate of the currently installed flash image, obtained as follows:
# dd if=/dev/mtd0 of=bios_imageI was just testing the BIOS flashing mechanism to see if it worked.
Ok. That sounds sane. Are you running linuxbios right now or something else?
Eric
Quoted 6 lines · Eric W. Biederman
Quoted 2 lines
What does "cached flash chip" mean? I have very little familiarity with how these flash chips operate.
The flash chips contents being cached in the cpus cache. cat
/proc/mtrrand see if covers the0xfff80000-0xffffffffrange where your flash chip lives.
The MTRR setup looks ok:
# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
#Quoted 5 lines
Quoted 1 line
How do I determine whether there is motherboard-specific magic?
Usually I see if I can read out the id on the flash chip. That tests to see if writes make it to the device because you have to write a command.
How do I do this?
Quoted 9 lines
Quoted 6 lines
The flash image I tried to install was an exact duplicate of the currently installed flash image, obtained as follows:
# dd if=/dev/mtd0 of=bios_imageI was just testing the BIOS flashing mechanism to see if it worked.
Ok. That sounds sane. Are you running linuxbios right now or something else?
Yes, I'm using linuxbios.
Quoted 8 lines · Dave Peterson
Quoted 6 lines · Eric W. Biederman
Quoted 2 lines
What does "cached flash chip" mean? I have very little familiarity with how these flash chips operate.
The flash chips contents being cached in the cpus cache. cat
/proc/mtrrand see if covers the0xfff80000-0xffffffffrange where your flash chip lives.
Quoted 5 lines
The MTRR setup looks ok:
# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 #
Ok. That plus the knowledge you are running under LinuxBIOS ensures me it isn't the cache.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
How do I determine whether there is motherboard-specific magic?
Usually I see if I can read out the id on the flash chip. That tests to see if writes make it to the device because you have to write a command.
How do I do this?
In dmesg it should print out what chip it finds. If you can write
to the chip you are clearly past that point.
Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
The flash image I tried to install was an exact duplicate of the currently installed flash image, obtained as follows:
# dd if=/dev/mtd0 of=bios_imageI was just testing the BIOS flashing mechanism to see if it worked.
Ok. That sounds sane. Are you running linuxbios right now or something else?
Yes, I'm using linuxbios.
The only thing I can possibly think of is that you didn't erase the chip after a dd to it from /dev/zero or something like that. As only resets can set bits to 1 that could trigger it. Although the error checking should catch that case. The cfi_command_set_1 isn't quite as paranoid as the AMD command set because it hasn't seen anywhere near as many problems.
I don't want to blame the code but I don't have a clue what is in 2.6.9, and I don't want to debug old code. As we are quickly running out of candidates I recommend testing the latest code.
I guess there is one additional possibility. You could be seeing aliases of the same chip. It is pretty unlikely but possible and if somehow the data was a different written to different parts of the aperture that could cause problems.
The only other thing I can think of is to recommend using lbflash as it automates this step and does a lot of checks along the way. Directly using the mtd device is ok but is much more error prone.
Eric