From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ash.lnxi.com ([207.88.130.242] helo=DLT.linuxnetworx.com) by pentafluge.infradead.org with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16P86U-0007jU-00 for ; Fri, 11 Jan 2002 20:16:42 +0000 To: Alice Hennessy Cc: David Woodhouse , linux-mtd@lists.infradead.org Subject: Re: Problem with cfi_probe.c and Intel chip References: <3C3E1515.CD99EB0@mvista.com> <17564.1010702853@redhat.com> <3C3E48B6.C9FF834D@mvista.com> From: ebiederman@lnxi.com (Eric W. Biederman) Date: 11 Jan 2002 13:27:36 -0700 In-Reply-To: <3C3E48B6.C9FF834D@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-mtd-admin@lists.infradead.org Errors-To: linux-mtd-admin@lists.infradead.org List-Help: List-Post: List-Subscribe: , List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: Alice Hennessy writes: > array > mode (0xff) would be necessary before the query command so I'm not sure why > my board is having problems. Even if the bios has issued a command to the > flash > between power up and cfi_probe, I don't think read array command is necessary > between commands. > If my board is the only Intel with a problem, then I need to investigate it > further. That would certainly be useful. My real suspicion is that this code hasn't been utilized all that much, and we are entering it's first real stabalization phase. Since all I did was comment out what looked like redundant code, I actually think you are the second person to notice this. Personally I have deal with boot block type flash memory, which may have different characteristics than other intel product lines. Having a couple of people get a firm grasp on what things cause problems, is probably needed right now. So if you come up with anything interesting I'd be glad to hear it. Eric