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

[Wolfgang Grandegger]

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 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).

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.