public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederman@lnxi.com (Eric W. Biederman)
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-mtd@lists.infradead.org
Subject: Re: ichxrom driver question
Date: Tue, 20 Dec 2005 18:40:13 -0700	[thread overview]
Message-ID: <m3vexjqlc2.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <200512201642.05224.dsp@llnl.gov> (Dave Peterson's message of "Tue, 20 Dec 2005 16:42:05 -0800")

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

  reply	other threads:[~2005-12-21  1:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21  0:42 ichxrom driver question Dave Peterson
2005-12-21  1:40 ` Eric W. Biederman [this message]
2005-12-21 18:37   ` Dave Peterson
2005-12-21 19:05     ` Eric W. Biederman
2005-12-22  2:12       ` Dave Peterson
2005-12-23  8:26         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3vexjqlc2.fsf@maxwell.lnxi.com \
    --to=ebiederman@lnxi.com \
    --cc=dsp@llnl.gov \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox