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 <[EMAIL PROTECTED]>
> 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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
