ichxrom driver question

ichxrom driver question

[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

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

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 dsp@llnl.gov.

Thanks,
Dave

Re: ichxrom driver question

[Eric W. Biederman]

Dave Peterson <dsp@llnl.gov> writes:

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

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

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

> Also, are there any known issues with
> the ICH3-S that may explain the behavior I observe?  When replying,
> please cc dsp@llnl.gov.

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

Re: ichxrom driver question

[Dave Peterson]

On Tuesday 20 December 2005 17:40, Eric W. Biederman wrote:
> 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.

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

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

Re: ichxrom driver question

[Eric W. Biederman]

Dave Peterson <dsp@llnl.gov> writes:

> On Tuesday 20 December 2005 17:40, Eric W. Biederman wrote:
>> 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.
>
>> 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.

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

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

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

Ok.  That sounds sane.  Are you running linuxbios right now or something
else?

Eric

Re: ichxrom driver question

[Dave Peterson]

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
    #

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

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

Re: ichxrom driver question

[Eric W. Biederman]

Dave Peterson <dsp@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