All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCHv3 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit	65nm flash chips.
Date: Tue, 17 Aug 2010 10:54:17 +0200	[thread overview]
Message-ID: <201008171054.17240.sr@denx.de> (raw)
In-Reply-To: <20100816135905.GA19517@frolo.macqel>

Hi Philippe,

the patch doesn't apply:

[stefan at stefan-desktop u-boot-cfi-flash (master)]$ git am -s -3 patches_misc/\[U-
Boot\]\ \[PATCHv3\ CFI\ flash\]\ Work\ around\ bug\ in\ Numonyx\ P33_P30\ 256-Mbit\  
65nm\ flash\ chips..mbox
Applying: Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
fatal: sha1 information is lacking or useless (with-numonyx-workaround.log).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

Not sure what's causing this. Perhaps some lines that should be removed from the 
commit log. Please see below:

On Monday 16 August 2010 15:59:05 Philippe De Muyter wrote:
> I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
> 256-Mbit 65nm flash chips.
> 
> After some time :( searching for bugs in our board or soft, we have
> discovered that those chips have a small but annoying bug, documented in
> "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> 
> It states :
> When customer uses [...] block unlock, the block lock status might be
> altered inadvertently. Lock status might be set to either 01h or 03h
> unexpectedly (00h as expected data), which leads to program/erase failure
> on certain blocks.
> 
> A working workaround is given, which I have applied and tested with success
> :
> 
> Workaround:  If the interval between 60h and its subsequent command
> 	     can be guaranteed within 20?s, Option I is recommended,
> 	     otherwise Option II (involves hardware) should be selected.
> Option I: The table below lists the detail command sequences:
> Command
> 	      Data bus           Address bus       Remarks
> Sequence
>   1              90h            Block Address
> 						   Read Lock Status
>   2             Read         Block Address + 02h
>  (2)(3)                                      (1)
> 3                60h           Block Address
>  (2)(3)                                      (1)   Lock/Unlock/RCR
> Configuration 4           D0h/01h/03h        Block Address
> Notes:
> (1) Block Address refers to RCR configuration data only when the 60h
>     command sequence is used to set RCR register combined with 03h
>     subsequent command.
> (2) For the third and fourth command sequences, the Block Address must
>     be the same.
> (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
>     commands should be less than 20?s.
> 
> And here is a log comparison of a simple (destructive) flash test without
> and with the workaround.
> 
> diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
> --- without-numonyx-workaround.log	2010-08-16 15:32:34.000000000 +0200
> +++ with-numonyx-workaround.log	2010-08-16 15:32:55.000000000 +0200
> @@ -1,33 +1,33 @@
> -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
> +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)

These lines might confuse git. I suggest that you remove it and resend the resulting 
patch again.

Thanks.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

      reply	other threads:[~2010-08-17  8:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16 13:59 [U-Boot] [PATCHv3 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips Philippe De Muyter
2010-08-17  8:54 ` Stefan Roese [this message]

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=201008171054.17240.sr@denx.de \
    --to=sr@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.