Other thing i notice in the following code:

--- /* Send the command for reading device ID */ this->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);

/* Read manufacturer and device IDs */ nand_maf_id = this->read_byte(mtd); nand_dev_id = this->read_byte(mtd); ---

It do this in UPM:

MAMR: 0xE0005070 pat_offset: 0x00000008 (write_command) MAR: 0xE0005068 cmd: 0x90 (read electronic signature)

MAMR: 0xE0005070 pat_offset: 0x00000010 (write_address) MAR: 0xE0005068 cmd: 0x00 (1st cycle)

But the read_byte() function doesnt change my #R pin (LGPL2)

From nand's datasheet, they said we need to perform two bus read operations,

so this shouldnt be throught UPM? Something like this:

run_pattern(0x00000000, 0x00); // not sure about second arg nand_maf_id = this->read_byte(mtd);

run_pattern(0x00000000, 0x00); nand_dev_id = this->read_byte(mtd);

I based my comments in this:

#define NAND_CMD_READ0 0x00 #define NAND_CMD_READID 0x90

UPM Routine Pattern offset Transaction ----------------- ----------------- ---------------

Read single 0x0 read_data Read burst 0x8 write_command 0x10 write_address Write single 0x18 write_data - 0x20–0x3F for others if needed

On Tue, Jul 29, 2008 at 10:22 AM, Alemao xcarandiru@gmail.com wrote:

Im using MPC8360E and NAND512W32BN6E, and they are connected like in mpc8360e-rdk (same pins).

About the waveform, i did the tests considering "reading the electronic signature" from the nand flash. I put the code below in a loop (nand_base.c):

---

   /* Select the device */
   this->select_chip(mtd, 0);

   /* Send the command for reading device ID */
   this->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);

   /* Read manufacturer and device IDs */
   nand_maf_id = this->read_byte(mtd);
   nand_dev_id = this->read_byte(mtd);

---

From nand datasheet, figure 28, when CL goes from LOW to HIGH, #W goes from HIGH to LOW, and in I/O the value for reading the electronic signature is passed.

But here with my board, CL is already in HIGH and then goes LOW.

As im using u-boot-1.1.4, i tried import the code from u-boot-1.3.3 and u-boot-1.3.4-rc1. Both i got the same result.

So, as my board is _based_ in mpc8360e-rdk, i was wondering if other configuration can affect the UPM.

Looking at the this->cmdfunc(...) (fun_cmdfunc at fsl_upm.c) it has some calls to fsl_upm_start_pattern, fsl_upm_run_pattern... and this functions activates the UPM. So it seems to be simple:

   command(READID)

   upm_start_pattern()
   upm_run_pattern(READID)
   upm_end_pattern()

   read_byte()

Im really curious to know what is causing the CL inversion.

Right now im trying to understand the UPM array. But its not so simple.

I have my doubts if my problem is the UPM array, since its working on mpc8360e-rdk and the same array is in App Note from Freescale.

Cheers,

-- Alemao

On Fri, Jul 25, 2008 at 2:33 PM, Anton Vorontsov avorontsov@ru.mvista.com wrote:

...

On Fri, Jul 25, 2008 at 01:50:41PM -0300, Alemao wrote:

...

Hi all,

I have a board based on the MPC8360E-RDK, and im trying to make NAND at local bus works with UPM. I put the scope to see what was going wrong and I got this:

                 ___

• the waveform in LGPL1/3 (nand CLE/ALE) should be ___| |___ ___ ___ but was |__|

The ascii art attempt failed. ;-)

[...]

...

One detail, im using u-boot-1.1.4 and i got the codes for UPM and NAND from u-boot-1.3.4-rc1.

Since the boards are pretty the same, I guess you can just compile the u-boot-1.3.3 (please try release instead of -rc, to be sure), and see if NAND will work. Maybe it will need really small code modifications for your board though.

Otherwise it is hard to say where is problem is (maybe the problem in the 1.1.4 nand core code, not in UPM setup?).

Also, you didn't mention what kind of chip the board is using.

Thanks,

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