Re: Invalid ONFI PARAM PAGE

[Miquel Raynal <miquel.raynal@bootlin.com>]

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/