[U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Anton Vorontsov]

On Thu, May 29, 2008 at 01:58:14PM +0200, Wolfgang Grandegger wrote:
> Anton Vorontsov wrote:
> > On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote:
> >> Scott Wood wrote:
> >>> On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
> >>>> This patch adds support for NAND FLASH on the TQM8548. It is disabled by
> >>>> default and can be enabled for the TQM8548 modules. Note that the R/B pin
> >>>> is not supported by that module requiring to use the specified maximum
> >>>> delay time.
> >>>>
> >>>> Note: With NAND support enabled the size of the U-Boot image exceeds
> >>>> 256 KB and TEXT_BASE must therefore be set to 0xfff80000 in config.mk,
> >>>> doubling the image size :-(.
> >>> What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?
> >> Maybe it does not support multi banks on a NAND chip. I have to check.
> > 
> > Me thinks that you'll have to call fsl_upm_nand_init() for each
> > chip, and that's all. If not, feel free to patch it as you feel appropriate,
> > I'll able to regress-test this driver on MPC8360E-RDK.
> 
> That seems not to be a minor problem. If CFG_MAX_NAND_DEVICE > 1,
> board_nand_init() will be called twice with the base address from
> CFG_NAND_BASE_LIST. The only problem I see is that the UPM interface is
> setup twice.

Personally I think we should remove UPM programming code from the
fsl_upm_nand.c, and program the UPM via its own interface, see this post:

From: David Saada <David.Saada at ecitele.com>
To: "'u-boot-users at lists.sourceforge.net'" <u-boot-users at lists.sourceforge.net>
Date: Mon, 19 May 2008 19:05:04 +0300
Subject: [U-Boot-Users] [PATCH][resubmit] MPC85xx, MPC83xx: Add/Fix UPM configuration support

^^^ But this is still WIP, and I'm not sure if this is suitable for our
needs (didn't try it).

> >>> How much of this is board-specific?
> >> Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
> >> get it working on this board. Therefore I decided to keep this known to
> >> work driver which we have already for a while.
> > 
> > This isn't really an excuse to duplicate drivers. :-) This driver was
> > tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic
> > changes. Some issues might still be there, and if so, fixes are highly
> > appreciated.
> 
> I know, sniff.
> 
> >> With Linux, I had more success.
> > 
> > ..especially if general idea works well, we should use single driver.
> 
> I already had a closer look and realized a difference in writing the UPM
> array. In fsl_upm.c there is:
> 
>   static void fsl_upm_setup(struct fsl_upm *upm)
>   {
> 	int i;
> 
> 	/* write upm array */
> 	out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
> 
> 	for (i = 0; i < 64; i++) {
> 		out_be32(upm->mdr, upm->array[i]);
> 		out_8(upm->io_addr, 0x0);
> 	}
> 
> 	/* normal operation */
> 	out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
> 	while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
> 		eieio();
>   }
> 
> But in my driver I fold the machine address into mbmr for each value:
> 
>         out_be32 (&lbc->mbmr,
>                  (in_be32 (&lbc->mbmr) & ~(MxMR_OP_NORM | MxMR_MAD)) |
>                   MxMR_OP_WARR | (i & MxMR_MAD));
>                                   ^

I see. I think there will be a problem with a

static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
{
        out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
}

static void fsl_upm_end_pattern(struct fsl_upm *upm)
{
        out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
        while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
                eieio();
}

Since it zeroes these values. No problem though, this should
be replaced by the Linux' versions, that is

clrsetbits_be32(upm->mxmr, MxMR_MAD, MxMR_OP_RP | pat_offset);
for start_pattern, and  clrbits32(upm->mxmr, MxMR_OP_RP); for
end_pattern.

So, this will leave your values intact, and will work for all boards as
well.

> Seem also that defines a duplicated :-(.

No problem. Please, remove the ones you don't like, and leave the ones
you do like. :-) Feel completely free to do everything you need to make
fsl_upm_nand.c work on your hardware, and then we'll see what we can do
to make our hardware work together.

As for UPM programming, as I've said, just remove UPM programming code
from the NAND driver, and leave it in the board file until (if) we'll
start using generic interface.

> Has it been tested with an MPC85xx? I will do some more test now.

Yup, MPC8555.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2