Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1188412 > unrolled thread

Re: [PATCH v5 07/12] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 07/12] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids  table Brian Norris <computersforpeace@gmail.com> - 2015-07-20 20:10 +0200
    Re: [PATCH v5 07/12] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2015-07-20 20:30 +0200

#1188412 — Re: [PATCH v5 07/12] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table

Hi Ezequiel,

On Sun, May 24, 2015 at 03:42:11PM -0300, Ezequiel Garcia wrote:
> On 05/20/2015 11:43 AM, Antoine Tenart wrote:
> [..]
> >>
> >> I just had a look on the datasheet, and I you're right, the nand should
> >> support JDEC. However I get a "No NAND device found" error when
> >> reverting this patch.
> >>
> >> It seems nand_flash_detect_jedec() is not reading "JDEC" and is returning
> >> directly. I'm having a look at this.
> > 
> > So, I can read 'J', 'E', 'D' and 'E' but then I got 0xff's. So I tried
> > to only check of JEDE in nand_flash_detect_jedec() but the JEDEC
> > parameter page was then not valid.
> > 
> 
> This uncovers two different bugs in the driver.
> 
> 1. read_id_bytes is either '2' or '4', but JEDEC detections needs at
> least 5 bytes.
> 
> 2. The initial buffer (to read the ID and the parameter page) has
> 256 bytes, but the JEDEC parameter page is 512-bytes.
> 
> And while at it, the driver doesn't seem to support reading the
> redundant parameter pages (recently reported on barebox ML [1]). So this
> is a third bug.
> 
> Would you try setting read_id_bytes to '5' and also increasing the READ_PARAM
> transfer length? Something like this:

I'm trying to parse through the latest pxa3xx_nand patches, and I'm a
bit lost. Did this piece get dropped on the floor?

At any rate, it looks like there are a few more things to fix in
Antoine's latest work, so I can't quite take them. Correct me if I'm
misunderstanding.

Thanks,
Brian

> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> index 1259cc5..851372f 100644
> --- a/drivers/mtd/nand/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/pxa3xx_nand.c
> @@ -48,7 +48,7 @@
>   * STATUS, READID and PARAM. The largest of these is the PARAM command,
>   * needing 256 bytes.
>   */
> -#define INIT_BUFFER_SIZE	256
> +#define INIT_BUFFER_SIZE	2048
>  
>  /* registers and bit definitions */
>  #define NDCR		(0x00) /* Control register */
> @@ -899,18 +899,18 @@ static int prepare_set_command(struct pxa3xx_nand_info *info, int command,
>  		break;
>  
>  	case NAND_CMD_PARAM:
> -		info->buf_count = 256;
> +		info->buf_count = 2048;
>  		info->ndcb0 |= NDCB0_CMD_TYPE(0)
>  				| NDCB0_ADDR_CYC(1)
>  				| NDCB0_LEN_OVRD
>  				| command;
>  		info->ndcb1 = (column & 0xFF);
> -		info->ndcb3 = 256;
> -		info->data_size = 256;
> +		info->ndcb3 = 2048;
> +		info->data_size = 2048;
>  		break;
> 
> [1] http://lists.infradead.org/pipermail/barebox/2015-May/023515.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1188422 — Re: [PATCH v5 07/12] mtd: nand: add Samsung K9GBG08U0A-M to nand_ids table

On 20 July 2015 at 15:08, Brian Norris <computersforpeace@gmail.com> wrote:
> Hi Ezequiel,
>
> On Sun, May 24, 2015 at 03:42:11PM -0300, Ezequiel Garcia wrote:
>> On 05/20/2015 11:43 AM, Antoine Tenart wrote:
>> [..]
>> >>
>> >> I just had a look on the datasheet, and I you're right, the nand should
>> >> support JDEC. However I get a "No NAND device found" error when
>> >> reverting this patch.
>> >>
>> >> It seems nand_flash_detect_jedec() is not reading "JDEC" and is returning
>> >> directly. I'm having a look at this.
>> >
>> > So, I can read 'J', 'E', 'D' and 'E' but then I got 0xff's. So I tried
>> > to only check of JEDE in nand_flash_detect_jedec() but the JEDEC
>> > parameter page was then not valid.
>> >
>>
>> This uncovers two different bugs in the driver.
>>
>> 1. read_id_bytes is either '2' or '4', but JEDEC detections needs at
>> least 5 bytes.
>>
>> 2. The initial buffer (to read the ID and the parameter page) has
>> 256 bytes, but the JEDEC parameter page is 512-bytes.
>>
>> And while at it, the driver doesn't seem to support reading the
>> redundant parameter pages (recently reported on barebox ML [1]). So this
>> is a third bug.
>>
>> Would you try setting read_id_bytes to '5' and also increasing the READ_PARAM
>> transfer length? Something like this:
>
> I'm trying to parse through the latest pxa3xx_nand patches, and I'm a
> bit lost. Did this piece get dropped on the floor?
>

As far as I can see, yes. Regarding this particular patch, the flash device
supports JEDEC detection but the driver needs a fix.

Hopefully, Antoine will submit a fix in the future.

> At any rate, it looks like there are a few more things to fix in
> Antoine's latest work, so I can't quite take them. Correct me if I'm
> misunderstanding.
>

The current patchset under discussion is "v2 mtd: pxa3xx_nand: rework
the timing setup":

http://lists.infradead.org/pipermail/linux-mtd/2015-July/060033.html

We are trying to get that sorted out, so we can move to the Berlin SoC support.

Cheers,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web