RE: NAND ECC in linux-omap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vimal,

> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@xxxxxxxxx]
> Sent: Saturday, August 28, 2010 2:07 AM
> To: Cliff Brake
> Cc: Ghorai, Sukumar; Kamat, Nishant; linux-omap@xxxxxxxxxxxxxxx; Linux MTD
> Subject: Re: NAND ECC in linux-omap
> 
> Adding LO and MTD list too for more comments.
> 
> On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh <vimal.newwork@xxxxxxxxx>
> wrote:
> > On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake <cliff.brake@xxxxxxxxx>
> wrote:
> >> On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake <cliff.brake@xxxxxxxxx>
> wrote:
> >>> On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar <s-ghorai@xxxxxx>
> wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Vimal Singh [mailto:vimal.newwork@xxxxxxxxx]
> >>>>> Sent: Tuesday, August 24, 2010 10:41 PM
> >>>>> To: Cliff Brake
> >>>>> Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
> >>>>> Subject: Re: NAND ECC in linux-omap
> >>>>>
> >>>>> On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@xxxxxxxxx>
> >>>>> wrote:
> >>>>> >
> >>>>> > flash_erasall -j /dev/mtd4
> >>>>>
> >>>>> Give a try without using '-j' option... If ECC layout is the
> suspect..
> >>>>> this may help.
> >>>> [Ghorai]
> >>>> Cliff,
> >>>> I did not able to spend much time on it to get into the problem.
> >>>> But would you please try using these additional patch(4) that yet to
> upstream?
> >>>> https://patchwork.kernel.org/patch/116554/
> >>>> https://patchwork.kernel.org/patch/116553/
> >>>> https://patchwork.kernel.org/patch/116555/
> >>>> https://patchwork.kernel.org/patch/116556/
> >>>> And select/change the proper ECC in -
> >>>> arch/arm/mach-omap2/board-flash.c: line No.148;
> >>>> board_nand_data.ecc_opt         = OMAP_ECC_HAMMING_CODE_HW;
> >>>
> >>> Thanks for the patches.  Now I get the following:
> >>>
> >>> root@ts3:~# flash_eraseall /dev/mtd1
> >>> Erasing 128 Kibyte @ 1c0000 -- 100 % complete.
> >>> root@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
> >>> Writing data to block 0 at offset 0x0
> >>>
> >>> And the operation hangs.
> >
> > Drop these patches. Please just give one more try after reverting last
> > 2 commits in omap2.c driver:
> > 1. omap3 nand: cleanup virtual address usages
> > and
> > 2. omap3 gpmc: functionality enhancement
> >
> > I suspect something wrong with patch '2'. I will look into it more.
> 
> I can see the problem in '1' patch only. In this patch, see below change:
> 
> ------------------------------------------
> 
> static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl)
>  {
>         struct omap_nand_info *info = container_of(mtd,
>                                         struct omap_nand_info, mtd);
> -       switch (ctrl) {
> -       case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_COMMAND;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_ADDRESS;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_NCE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -       }
> 
> -       if (cmd != NAND_CMD_NONE)
> -               __raw_writeb(cmd, info->nand.IO_ADDR_W);
> +       if (cmd != NAND_CMD_NONE) {
> +               if (ctrl & NAND_CLE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND,
> cmd);
> +
> +               else if (ctrl & NAND_ALE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS,
> cmd);
> +
> +               else /* NAND_NCE */
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA,
> cmd);
> +       }
>  }
> 
> ---------------------------------------------
> 
> The new (changed) hwcontrol routine still can latch command and
> address to correct gpmc nand registers. But it is failing to set '
> info->nand.IO_ADDR_W' and 'info->nand.IO_ADDR_R'.
> Which will be used by write/read routines to:  write to (IO_ADDR_W) or
> read from (IO_ADDR_R).
[Ghorai]
1. You mean revert the old code will solve the issue mentioned by Cliff? 
2. Can you check if the problem already exists before applying these patch itself?
 
> 
> 
> --
> Regards,
> Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux