ichxrom driver question

[Eric W. Biederman]

Dave Peterson <dsp at llnl.gov> writes:

> On Wednesday 21 December 2005 11:05, Eric W. Biederman wrote:
>> > 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.
>
> 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.

>> > 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. 

>> > 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.
>>
>> 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