[U-Boot-Users] NAND driver question

[Stefan Roese <sr@denx.de>]

On Monday 04 February 2008, Craig Millen wrote:
> > I may have noted this before, but I suggest you move the CFG_NAND_ADDR
> > to 0x90000000 as done on Bamboo, since 0xd0000000 is reserved for PCI
> > memory on 440EP.
>
> 	I have done this and it didn't make any difference, same
> exception

I know. But I still recommend to make this address switch, since this area 
*is* reserved for PCI memory.

> > How is SDR0_CUST0 configured. Please read is in a running system and
> > send me the value. And how is the GPIO/multiplexing configured?
>
> 	a0200004
>
> > BTW: It would be much easier to help you here, if you board port was
> > available in the official U-Boot repository. I suggest you submit this
> > support soon.
>
> 	I would love to, but I am not sure how to add all of our code to
> the repository because it is rather heavily customized and there are a
> lot of files that would conflict with what is in the u-boot git
> repository.

And you can't implement your changes in a more "clean way"? What exactly is 
the problem? The 440EP is already supported, so changes to the common files 
shouldn't be that big. And all board specific stuff should go into your board 
directory anyways.

> >> We have noticed however that when reading from the nand in u-boot,
> >> that the /CE line is never deasserted between page reads, but in the
> >> linux kernel user mode, it is.  We have yet to figure out why this
> >> is.
>
> > That's possible. Could be that the U-Boot NAND driver doesn't deassert
> > the CE line.
>
> 	This turned out to be the culprit.

So with this change, 32bit access is working too?

> 	The NAND data sheet 
> stipulates that the CE line "should" deassert after a sequential read
> for 100ns. I ported the code from the NDFC drive in linux and added it
> to ndfc.c and we no longer see any missed bytes even on huge files
> (80Mb). I would highly suggest merging it into the u-boot ndfc driver.
> Perhaps the NAND chips that you are testing on aren't susceptible to
> this, but there are some that are.

Which NAND chips are you using? And could you please send this fix as a "real" 
patch with Signed-off-by etc? That would be helpful.

> static void ndfc_select_chip(struct mtd_info *mtdinfo, int chip)
> {
> 	uint32_t ccr;
> 	struct nand_chip *this = mtdinfo->priv;
> 	ulong base = (ulong) this->IO_ADDR_W & 0xfffffffc;
> 	int cs = (ulong)this->IO_ADDR_W & 0x00000003;
>
>
> 	ccr = in_be32((u32 *)(base + NDFC_CCR));
>
> 	if (chip >= 0) {
> 		ccr &= ~NDFC_CCR_BS_MASK;
> 		ccr |= NDFC_CCR_BS(chip + cs);
> 	} else
> 		ccr |= NDFC_CCR_RESET_CE;
> 	out_be32((u32 *)(base + NDFC_CCR), ccr);
> }
>
> Then in board_nand_init add the "select_chip" pointer to point to the
> ndfc_select_chip function
> int board_nand_init(struct nand_chip *nand)
> {
> 	int cs = (ulong)nand->IO_ADDR_W & 0x00000003;
> 	ulong base = (ulong)nand->IO_ADDR_W & 0xfffffffc;
>
> 	nand->hwcontrol  = ndfc_hwcontrol;
> 	nand->read_byte  = ndfc_read_byte;
> 	nand->read_buf   = ndfc_read_buf;
> 	nand->write_byte = ndfc_write_byte;
> 	nand->dev_ready  = ndfc_dev_ready;
> 	nand->select_chip = ndfc_select_chip;
> ...
> ...
>
> All of the code to actually use the "selec_chip" is already there in
> nand_base.c
>
> >What frequency is your EBC clocked? Did you try lower access speeds,
>
> something
>
> >like:
>
> 	We use a 66MHz EBC clock
>
> >	out_be32((u32 *)(base + NDFC_BCFG0 + (cs << 2)), 0x80007777);
>
> 	Yes, I did try this and it gave me a machine check exception as
> well. This doesn't change the EBC frequency though, it is just
> "supposed" to change the number of EBC ticks that it waits for.

Understood.

Best regards,
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
=====================================================================