mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Eric Bénard" <eric@eukrea.com>
To: Vanalme Filip <F.Vanalme@TELEVIC.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: NAND flash
Date: Tue, 22 Mar 2011 10:04:39 +0100	[thread overview]
Message-ID: <4D886627.1040900@eukrea.com> (raw)
In-Reply-To: <6EE7D1502C48E44E92DCADF9DD3E0DB9017FF3BF5262@SRV-VS06.TELEVIC.COM>

Hi Filip,

On 22/03/2011 09:41, Vanalme Filip wrote:
> Are you sure about this ?
> This is a fragment from a Freescale application note on NAND flashes (draft version however...).
>
> (there's a flowchart just above this explanation - I removed it because I think it's not that important for now)
>
> "The red dash line is the nand flash internal boot codes routine. There will be some important check points:
> 1:If BOOT_INT fuse is 0x1, The internal boot will be enabled.
> 2:If IROM_SUPPORT_EN fuse is 0x1, The ROM codes will be enabled.
> 3:ROM codes will read GPCR register to check the boot pin settings.
> 4:ROM codes will enable the Nand flash support, and get the Nand flash IO bus width by the value from boot pin settings.
> 5:ROM codes will read ADD_CYCLE[1:0] to get the right Nand flash access cycle.
> 6:ROM codes will send Nand flash reset command to Nand flash.
>     Note: Micron flash(and the same alliance Nand flash manufacture need the reset command before operation the flash, Our external will not send out the command, Enable internal boot will enable this type of flash)
> 7:ROM codes will read the first 2K page datum from flash to Nand flash controller buffer(Address 0xd8000000).
> 8:ROM codes will check the CSF/DCD segment, but if the chipset HAB type is engineer version, It will just log the error message and jump to load address directly, Please check details in the follow section."
>
> Remark item 6...
>
yes I also saw this document, but Freescale told us several times that nand 
boot on Micron flash is not working so I didn't investigate more as we have 
NOR boot as a default on this platform ... and have switched to i.MX25 & 35 
for new applications.

> Fragment from another Freescale doc :
>
> "►Option 1: Connect POR_B reset signal to NAND_Init
> • Only available on NAND Flash devices that have the NAND_Init pin.
> ►Option 2: Use Internal Boot Mode
> • Requires eFuses to be programmed to enable Internal Boot Mode,
> select NAND Flash address cycles and iROM support enable.
> • Add NAND Flash Header to NAND to support iROM Boot.
> ►Option 3: Double POR_B reset to i.MX27
> • Initial POR_B will generate a hidden Reset in the NAND Flash when
> i.MX27 performs initial NAND Flash read cycle.
> • Reassert then deassert POR_B to re-generate the initial NAND Flash
> read cycle.
> • Hidden NAND Flash reset will NOT occur since power was not removed
> from the NAND Flash.
> • Small uC can be used to generate the timing."
>
> See option 2...
>
> At the moment, we are working on i.MX27PDK boards. I just checked the version id : 2. Title of the application note : "iMx27 TO2 Internal Boot". So, I guess this is intended for our version.
>
> If I'm right, your company is also manufacturer of i.MX27 based boards. Therefore, I tend to rely on your experience with that processor. Moreover, the application note is still a "draft" version... On the other hand, Freescale confirmed that we could use that kind of Micron NAND flashes without any problem. They even reviewed our own board design and made no remarks with respect to the NAND flash (no remarks on adding extra logic to support that type of NAND)...
> This is a very confusing situation and it might result in a redesign of our board...
>
I've not worked enough on nand boot on i.MX27 to provide more feedback but FSL 
& Micron recommended us the workaround implying a double POR for nand boot.

The problem is that sometime workaround sent by support that are not even 
tested and sometime there are things in the documentation which are also not 
tested or even not present in the CPU so it's difficult to know where is the 
truth without spending time on this problem ...

Eric

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2011-03-22  9:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 15:19 Vanalme Filip
2011-03-21 16:11 ` Eric Bénard
2011-03-22  8:41   ` Vanalme Filip
2011-03-22  9:04     ` Eric Bénard [this message]
2011-03-22 12:21       ` Vanalme Filip

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=4D886627.1040900@eukrea.com \
    --to=eric@eukrea.com \
    --cc=F.Vanalme@TELEVIC.com \
    --cc=barebox@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