Invalid ONFI PARAM PAGE

Invalid ONFI PARAM PAGE

[Marco Felsch]

Hi,

a customer of us uses micron nand flash devices for their local storage.
They are now having some troubles with a few devices. Let me start with
the following:
  1) We can successfully read the nand id field by:
     -> select_chip
     -> cmdfunc(mtd, NAND_CMD_RESET)
     -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x00
     -> 8times: read_byte(mtd)

     The NAND device response with the following:
     nand: id_data[0]: 0x2c
     nand: id_data[1]: 0xdc
     nand: id_data[2]: 0x90
     nand: id_data[3]: 0x95
     nand: id_data[4]: 0x56
     nand: id_data[5]: 0x0
     nand: id_data[6]: 0x0
     nand: id_data[7]: 0x0

     Accroding the schematic and the datasheet this is right.

  2) To detect the ONFI compatibility we now issue:
     -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x20

     and getting the expected 'O','N','F','I' signature.

   3) Now we are trying to Read the PARAM Page by:
      -> cmdfunc(mtd, NAND_CMD_PARAM)
      -> try to read the the param page and if not successful try to
         read the copies.

      Here things getting crazy since we are reading all the time '0xff'.

   4) Since Barebox (Bootloader) can't read the ONFI param page we
      calculate the values as expected from the param page. But now we
      can't access BBT (not found) nor we are not able to write to the
      OOB Area (the chip is not write protected).

The electrical signals are looking good and since we can retrieve the
id-data it should be no PCB bug. Did anyone struggled with such problems
too?

BTW:
I also get '0xff' if I send a READ_UNIQUE_ID command and trying to read
the 16 copies of the 32byte unique-id.

Any answers are welcome :)

Regards,
  Marco

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Invalid ONFI PARAM PAGE

[Miquel Raynal]

Hi Marco,

Marco Felsch <m.felsch@pengutronix.de> wrote on Thu, 30 Jul 2020
14:14:25 +0200:

> Hi,
> 
> a customer of us uses micron nand flash devices for their local storage.
> They are now having some troubles with a few devices. Let me start with
> the following:
>   1) We can successfully read the nand id field by:
>      -> select_chip
>      -> cmdfunc(mtd, NAND_CMD_RESET)
>      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x00
>      -> 8times: read_byte(mtd)  
> 
>      The NAND device response with the following:
>      nand: id_data[0]: 0x2c
>      nand: id_data[1]: 0xdc
>      nand: id_data[2]: 0x90
>      nand: id_data[3]: 0x95
>      nand: id_data[4]: 0x56
>      nand: id_data[5]: 0x0
>      nand: id_data[6]: 0x0
>      nand: id_data[7]: 0x0
> 
>      Accroding the schematic and the datasheet this is right.
> 
>   2) To detect the ONFI compatibility we now issue:
>      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x20  
> 
>      and getting the expected 'O','N','F','I' signature.
> 
>    3) Now we are trying to Read the PARAM Page by:
>       -> cmdfunc(mtd, NAND_CMD_PARAM)
>       -> try to read the the param page and if not successful try to  
>          read the copies.
> 
>       Here things getting crazy since we are reading all the time '0xff'.
> 
>    4) Since Barebox (Bootloader) can't read the ONFI param page we
>       calculate the values as expected from the param page. But now we
>       can't access BBT (not found) nor we are not able to write to the
>       OOB Area (the chip is not write protected).
> 
> The electrical signals are looking good and since we can retrieve the
> id-data it should be no PCB bug. Did anyone struggled with such problems
> too?
> 
> BTW:
> I also get '0xff' if I send a READ_UNIQUE_ID command and trying to read
> the 16 copies of the 32byte unique-id.
> 
> Any answers are welcome :)

Could you share more details about the situation your customer is
facing? Did this work before? Is this an update? If yes from what
version to what version? Also, is this a Linux or Barebox issue?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Invalid ONFI PARAM PAGE

[Marco Felsch]

Hi Miquel,

thanks for your response :)

On 20-08-03 10:47, Miquel Raynal wrote:
> Hi Marco,
> 
> Marco Felsch <m.felsch@pengutronix.de> wrote on Thu, 30 Jul 2020
> 14:14:25 +0200:
> 
> > Hi,
> > 
> > a customer of us uses micron nand flash devices for their local storage.
> > They are now having some troubles with a few devices. Let me start with
> > the following:
> >   1) We can successfully read the nand id field by:
> >      -> select_chip
> >      -> cmdfunc(mtd, NAND_CMD_RESET)
> >      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x00
> >      -> 8times: read_byte(mtd)  
> > 
> >      The NAND device response with the following:
> >      nand: id_data[0]: 0x2c
> >      nand: id_data[1]: 0xdc
> >      nand: id_data[2]: 0x90
> >      nand: id_data[3]: 0x95
> >      nand: id_data[4]: 0x56
> >      nand: id_data[5]: 0x0
> >      nand: id_data[6]: 0x0
> >      nand: id_data[7]: 0x0
> > 
> >      Accroding the schematic and the datasheet this is right.
> > 
> >   2) To detect the ONFI compatibility we now issue:
> >      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x20  
> > 
> >      and getting the expected 'O','N','F','I' signature.
> > 
> >    3) Now we are trying to Read the PARAM Page by:
> >       -> cmdfunc(mtd, NAND_CMD_PARAM)
> >       -> try to read the the param page and if not successful try to  
> >          read the copies.
> > 
> >       Here things getting crazy since we are reading all the time '0xff'.
> > 
> >    4) Since Barebox (Bootloader) can't read the ONFI param page we
> >       calculate the values as expected from the param page. But now we
> >       can't access BBT (not found) nor we are not able to write to the
> >       OOB Area (the chip is not write protected).
> > 
> > The electrical signals are looking good and since we can retrieve the
> > id-data it should be no PCB bug. Did anyone struggled with such problems
> > too?
> > 
> > BTW:
> > I also get '0xff' if I send a READ_UNIQUE_ID command and trying to read
> > the 16 copies of the 32byte unique-id.
> > 
> > Any answers are welcome :)
> 
> Could you share more details about the situation your customer is
> facing? Did this work before? Is this an update? If yes from what
> version to what version? Also, is this a Linux or Barebox issue?

This issue get's triggered right after the first start-up. Some devices
do work and some of them don't after the production. I think it's not a
Linux nor a Barebox issue. Since Barebox can't find the BBT and all
other stuff I skipped propper Linux tests. I will test if Linux can
identify and setup the chip. But I think Linux will setp into the same
NAND-Issues.

I asked on this ML since you guys are the Experts here and maybe you had
see a 'not full prefactored' NAND device too.

Regards,
  Marco

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Invalid ONFI PARAM PAGE

[Miquel Raynal]

Hi Marco,

Marco Felsch <m.felsch@pengutronix.de> wrote on Mon, 3 Aug 2020
11:06:26 +0200:

> Hi Miquel,
> 
> thanks for your response :)
> 
> On 20-08-03 10:47, Miquel Raynal wrote:
> > Hi Marco,
> > 
> > Marco Felsch <m.felsch@pengutronix.de> wrote on Thu, 30 Jul 2020
> > 14:14:25 +0200:
> >   
> > > Hi,
> > > 
> > > a customer of us uses micron nand flash devices for their local storage.
> > > They are now having some troubles with a few devices. Let me start with
> > > the following:
> > >   1) We can successfully read the nand id field by:  
> > >      -> select_chip
> > >      -> cmdfunc(mtd, NAND_CMD_RESET)
> > >      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x00
> > >      -> 8times: read_byte(mtd)    
> > > 
> > >      The NAND device response with the following:
> > >      nand: id_data[0]: 0x2c
> > >      nand: id_data[1]: 0xdc
> > >      nand: id_data[2]: 0x90
> > >      nand: id_data[3]: 0x95
> > >      nand: id_data[4]: 0x56
> > >      nand: id_data[5]: 0x0
> > >      nand: id_data[6]: 0x0
> > >      nand: id_data[7]: 0x0
> > > 
> > >      Accroding the schematic and the datasheet this is right.
> > > 
> > >   2) To detect the ONFI compatibility we now issue:  
> > >      -> cmdfunc(mtd, NAND_CMD_READID) Addr=0x20    
> > > 
> > >      and getting the expected 'O','N','F','I' signature.
> > > 
> > >    3) Now we are trying to Read the PARAM Page by:  
> > >       -> cmdfunc(mtd, NAND_CMD_PARAM)
> > >       -> try to read the the param page and if not successful try to    
> > >          read the copies.
> > > 
> > >       Here things getting crazy since we are reading all the time '0xff'.
> > > 
> > >    4) Since Barebox (Bootloader) can't read the ONFI param page we
> > >       calculate the values as expected from the param page. But now we
> > >       can't access BBT (not found) nor we are not able to write to the
> > >       OOB Area (the chip is not write protected).
> > > 
> > > The electrical signals are looking good and since we can retrieve the
> > > id-data it should be no PCB bug. Did anyone struggled with such problems
> > > too?
> > > 
> > > BTW:
> > > I also get '0xff' if I send a READ_UNIQUE_ID command and trying to read
> > > the 16 copies of the 32byte unique-id.
> > > 
> > > Any answers are welcome :)  
> > 
> > Could you share more details about the situation your customer is
> > facing? Did this work before? Is this an update? If yes from what
> > version to what version? Also, is this a Linux or Barebox issue?  
> 
> This issue get's triggered right after the first start-up. Some devices
> do work and some of them don't after the production. I think it's not a
> Linux nor a Barebox issue. Since Barebox can't find the BBT and all
> other stuff I skipped propper Linux tests. I will test if Linux can
> identify and setup the chip. But I think Linux will setp into the same
> NAND-Issues.
> 
> I asked on this ML since you guys are the Experts here and maybe you had
> see a 'not full prefactored' NAND device too.
> 
> Regards,
>   Marco

Thanks for detailing, I understand your problem now. Well I honestly
don't have any idea why a flashing process would work with a chip and
totally fail otherwise, if not a hardware issue. Maybe there is a
clocking specificity?

Sorry for not being helpful at all :)
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/