public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Shiju Mathew <mshiju@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Flash Erase/Write error in uboot
Date: Tue, 08 May 2007 14:36:40 -0400	[thread overview]
Message-ID: <1178649400.8335.26.camel@localhost> (raw)
In-Reply-To: <c166aa9f0705050648p16b150c2sfb123108f7b0bce6@mail.gmail.com>

On Sat, 2007-05-05 at 08:48 -0500, Andrew Dyer wrote:
> On 5/4/07, Shiju Mathew <mshiju@gmail.com> wrote:
> > I was debugging the problem further. We have two other bootloaders running
> > on this board - redboot and Eboot. Both does not have this problem. Only on
> > Uboot I am experiencing this problem. On debugging what I could find is that
> > when I erase a sector, the function flash_is_busy() returns immidiatly with
> > success(not busy). Usually it should loop for a while in this function
> > before returning that the flash is not busy. Before writing to the erased
> > sector, the "md" command displayed 0xffffffff for the erased sector. But
> > when I tried to write data to the erased location using cp.b, the function
> > flash_write_cfiword() returns with error "flash is not erased" since it
> > failed to find 0xffffffff in the erased locations(Check if Flash is
> > (sufficiently) erased). So why does "md" displays 0xffffffff for erased
> > locations and flash routine says it is not 0xffffffff ? Could someone
> 
> I suspect the code is reading the status word instead of the array
> data.  You have to be careful with handling the array, as there is no
> separate status port, so the status data will show up as read data if
> you aren't careful.
> 
> One thing you might check is to make sure the flash 'timeout' variable
> isn't getting set to zero.  I found a problem with this a long time
> ago - it had to do with how the CFI timeout data (reported in usec)
> was being converted to a value for timeout (in msec).  If timeout was
> zero, the status read stuff would time out before reding the data the
> second time through.  I think was fixed, but it's worth checking.
> 
Thanks for all your comments. I could get a few sector erase/write
success if I reduce the system clock to 398 MHz and bus speed to 66 MHz
and also make the below changes for erase status check. Previouly it was
running at 532 MHz/133 MHz (CPU/bus).Now I could update uboot without
any problem.  But if I try to erase/write large no: of sectors, says 100
sectors, it fails with the same error as before. So I think the problem
is realated to timming.
			
#define TIMEOUT 10000000
               timeout = TIMEOUT;
                while (1) {
                     if (flash_isset (info, sect, 0, 0x08)) {
	                    debug("Operation complete\n");
         	            break;
                      }
                      if (!timeout--) {
                             printf("Operation Timed Out!!n");
                             break;
                      }
               }
               timeout = TIMEOUT;
               while (1) {
                      if (flash_isset (info, sect, 0,
FLASH_STATUS_DONE)) {
                            debug("Flash erase done\n");
                            break;
                      }
                      if (!timeout--) {
                            printf("Erase Timed Out!!\n");
                            break;
                      }
              }


> Check how CS configuration etc. is correctly configured. If it is 
> working with the extension board not installed but not obviously you 
> have something wrong. It could be that your CS1 configuration is 
> incorrect. Possibilities are endless. But I do not see this as a
> flash 
> driver issue.

If I disconnected the extension board, I don't have any issues. I could
also run the system at 532/133 MHz without any flash write issues. The
problem happens when the load increases on the bus. I made sure that the
CS are configured right.I disabled CS1( where extension board is
connected) without any success.

> Wow, 3 bootloaders for one board! What luxury. :)
> 
We got eboot and redboot along with the board. But we want to move to
uboot to support all the OS runnning on the board because of its feature
rich and has good support from the community.

Thanks,
Shiju

  parent reply	other threads:[~2007-05-08 18:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02  0:22 [U-Boot-Users] Flash Erase/Write error in uboot Shiju Mathew
2007-05-02  0:29 ` Wolfgang Denk
2007-05-02 16:24   ` Shiju Mathew
2007-05-02 23:10     ` Tolunay Orkun
2007-05-03 18:40       ` Shiju Mathew
2007-05-03 21:31         ` Tolunay Orkun
2007-05-05  2:46           ` Shiju Mathew
2007-05-05  5:18             ` Stefan Roese
2007-05-05  5:26             ` Tolunay Orkun
     [not found]             ` <c166aa9f0705050648p16b150c2sfb123108f7b0bce6@mail.gmail.com>
2007-05-08 18:36               ` Shiju Mathew [this message]
2007-05-08 18:59                 ` Wolfgang Denk
2007-05-02  5:01 ` Stefan Roese

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=1178649400.8335.26.camel@localhost \
    --to=mshiju@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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