From: Vanalme Filip <F.Vanalme@TELEVIC.com>
To: "Eric Bénard" <eric@eukrea.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: RE: NAND flash
Date: Tue, 22 Mar 2011 09:41:50 +0100 [thread overview]
Message-ID: <6EE7D1502C48E44E92DCADF9DD3E0DB9017FF3BF5262@SRV-VS06.TELEVIC.COM> (raw)
In-Reply-To: <4D8778A6.3000503@eukrea.com>
> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: maandag 21 maart 2011 17:11
> To: Vanalme Filip
> Cc: barebox@lists.infradead.org
> Subject: Re: NAND flash
>
> Hi,
>
> On 21/03/2011 16:19, Vanalme Filip wrote:
> > On our own i.MX27 based boards, we have Micron NAND flash memory
> > (MT29F2G08ABBEAH4). Besides the BI-swapping problem for 2K NAND
> flashes, I can
> > see that this chip needs an initial reset command before it becomes
> > operational. This is something that has to be done in the early boot code, so
> > before loading the first page of bootloader code (the reset should be sent
> > before the first page of code can be read from flash).
> >
> > From Freescale doc, I found that we have to blow certain fuses to make the
> > i.MX27 boot from internal ROM. According to the document, the ROM code takes
> > care about the initial reset before loading the first page of code from the
> > NAND flash.
> >
> > I’m however a little concerned about this figure in the document :
> >
> > If I understand well, this should be the structure of the 2K NFC buffer when
> > booting from internal ROM. I don’t think this will be the structure when
> > loading the first page of Barebox code, correct ?
> >
> > Anyone familiar with this Micron specific flash problem ? And the consequences
> > for Barebox ? Do we have to make modifications in the Barebox code to tackle
> > this ?
> >
> > (because the Freescale document is rather WinCE related, I’m not sure this
> > also applies to Barebox/Linux based systems…)
> >
> > I hope we didn’t make a bad choice of NAND flash in combination with i.MX27…
> ? ;-)
> >
> this may be the case as unless this has changed recently, flash requiring a
> reset command can't be used on i.MX27 for nand boot without extra logic as the
> internal bootrom doesn't send this reset command.
>
> Eric
[Filip] Hi Eric,
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...
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...
Other forum members with i.MX27/Micron NAND experience ?
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2011-03-22 8:41 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 [this message]
2011-03-22 9:04 ` Eric Bénard
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=6EE7D1502C48E44E92DCADF9DD3E0DB9017FF3BF5262@SRV-VS06.TELEVIC.COM \
--to=f.vanalme@televic.com \
--cc=barebox@lists.infradead.org \
--cc=eric@eukrea.com \
/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