Anton Vorontsov wrote:
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@ecitele.com To: "'u-boot-users@lists.sourceforge.net'" u-boot-users@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).
OK.
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.
Fix that, but I can still not access the device properly. I'm a bit puzzled because it uses a different algorithm to access the device. While my and the Linux fsl_upm driver uses NAND_ALE, NAND_CLE and friends to manage the access via hwcontrol callback, the fsl_upm driver of U-Boot uses the cmdfunc callback doing different things. What is the difference? It seems to work on the MPC8555, at least, as you mention below.
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.
OK. The defines should go to fsl_lbc.h nowadays.
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.
Wolfgang.