[U-Boot] [PATCH v5] Corrupted NAND Flash access on KARO TX25 modules.

[Benoît Thébaudeau]

Dear Daniel, Scott,

On Thu, Aug 2, 2012 at 03:55:51 PM, Benoît Thébaudeau wrote:
> On Thu, Aug 2, 2012 at 01:28:08 PM, Benoît Thébaudeau wrote:
> > On Thu, Aug 2, 2012 at 01:17:07 PM, Daniel Gachet wrote:
> > > The mxc_nand driver uses the symmetric mode to access the NAND
> > > Flash,
> > > but the
> > > devices populated on the KARO TX25 only support ann asymmetic
> > > mode
> > > (MX25: bit 8 within NAND_FLAHS_CONFIG1 register cleared).
> > > 
> > > This patch enables to selected the NAND Flash access mode with
> > > the
> > > configuration flag CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES.
> [snip]
> > Why don't you simply add a factor of two to the CCM NFC divider in
> > lowlevel_init.S?
> 
> To be more specific, I also have hardware based on the i.MX25 that
> does not use
> the NAND Flash from the reference design. It works fine with the
> symmetric mode
> as long as the NFC prescaler is set up appropriately in the MMC. I
> don't think
> that it is possible that a NAND Flash device does not support
> symmetric mode. So
> there should not be any need for a CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES
> config
> option.
> 
> All you have to do is to set the appropriate value in PER8 DIV in
> PCDR2 (address
> 0x53f80020). This can easily be added as a single line to the
> init_clocks macro
> in board/karo/tx25/lowlevel_init.S. Since the TX25 board does not set
> this
> register, it is left at its reset value, which is 0x01010101, so the
> line to add
> would be (dividing the NFC clock twice more):
> 	write32 0x53f80020, 0x01010103
> 
> This patch is interfering with a patch series that I'd like to post
> today or
> tomorrow, so please make a quick decision about this, so that I can
> know if I
> should take this patch into account for my series or if I should
> ignore it.

Did you have a chance to test my suggestion on Karo TX25? Do you want me to send
a patch for it?

Except if adding this config option to the driver adds a real benefit compared
to my suggestion, it is probably better to tune the board files first.

Best regards,
Benoît