public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Shiyan <eagle.alexander923@gmail.com>
Cc: JaimeLiao <jaimeliao.tw@gmail.com>,
	linux-mtd@lists.infradead.org,
	"Bean Huo (beanhuo)" <beanhuo@micron.com>
Subject: Re: Boot failed after patch "mtd: rawnand: Support for sequential cache reads"
Date: Mon, 29 May 2023 13:46:19 +0200	[thread overview]
Message-ID: <20230529134619.255d0b07@xps-13> (raw)
In-Reply-To: <CAP1tNvRTRkXMztGL=nxrd-Cv5xO58-R=A_M2r65d6cyidoVz0g@mail.gmail.com>

Hi Bean,

I'm adding you to this thread because I'm clueless regarding what's
happening to Alexander.

Short recap: sequential page reads seem to fail with an MT29F Micron
chip. Alexander is using a gpmc controller without on-die ECC, I doubt
the error comes from the controller, so I would like to know if there
is anything known to fail with these chips regarding the use of
sequential reads. We can easily work around that situation if we
identify the problem.

Thanks a lot,
Miquèl

eagle.alexander923@gmail.com wrote on Mon, 29 May 2023
13:33:04 +0300:

> пн, 29 мая 2023 г. в 11:12, Miquel Raynal <miquel.raynal@bootlin.com>:
> ...
> According to the MT29F2G08ABAEAWP datasheet, the chip supports
> > > the READ PAGE CACHE SEQUENTIAL opcode, but with two caveats:
> > >  4. These commands supported only with ECC disabled.
> > >  5. Issuing a READ PAGE CACHE series (31h, 00h-31h, 3Fh) command
> > >   when the array is busy (RDY = 1, ARDY = 0) is supported if the previous
> > >   command was a READ PAGE (00h-30h) or READ PAGE CACHE series
> > >   command; otherwise, it is prohibited.
> > >
> > > As far as I understand, the second remark suits us, since we create
> > > the correct sequence.  
> >
> > Exactly, we do:
> >
> >         READ0 (0), READSTART (30),
> >         READCACHESEQ (31), data,
> >         READCACHESEQ (31), data,
> >         ...
> >         READCACHEEND (3f), data.
> >
> > which is what the datasheet tells us I believe.
> >  
> > > But the first remark can be a problem in this case.  
> >
> > I was not aware of this limitation, it's only written in the summary,
> > not in the details about the commands, nice finding. We need to prevent
> > on-die ECC users from enabling this feature.
> >
> > But given the below trace, you're not using the on-die ECC engine,
> > right? It looks like you're using the controller's ELM engine to
> > perform ECC correction, so I don't see why this specific limitation
> > would hit us. Can you confirm the ECC engine of the chip is disabled?  
> 
> Yes, on-die ECC is disabled.
> Please advise where I can insert some debug messages to clear things up.
> 
> > > > > omap-gpmc 50000000.gpmc: GPMC revision 6.0
> > > > > ...
> > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > > nand: Micron MT29F2G08ABAEAWP
> > > > > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
> > > > > ...
> > > > > VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
> > > > > devtmpfs: mounted
> > > > > Freeing unused kernel image (initmem) memory: 1024K
> > > > > Run /sbin/init as init process
> > > > > SQUASHFS error: lzo decompression failed, data probably corrupt
> > > > > SQUASHFS error: Failed to read block 0xd291c2: -5
> > > > > SQUASHFS error: lzo decompression failed, data probably corrupt
> > > > > SQUASHFS error: Failed to read block 0xd291c2: -5
> > > > > SQUASHFS error: Unable to read data cache entry [d291c2]
> > > > > SQUASHFS error: Unable to read page, block d291c2, size 14307
> > > > > SQUASHFS error: Unable to read data cache entry [d291c2]
> > > > > SQUASHFS error: Unable to read page, block d291c2, size 14307
> > > > > Kernel panic - not syncing: Attempted to kill init!
> > > > > exitcode=0x00000007 CPU: 0 PID: 1 Comm: init Not tainted 6.3.0+ #105
> > > > > Hardware name: Generic AM33XX (Flattened Device Tree)
> > > > >  unwind_backtrace from show_stack+0xb/0xc
> > > > >  show_stack from dump_stack_lvl+0x2b/0x34
> > > > >  dump_stack_lvl from panic+0xbd/0x230
> > > > >  panic from make_task_dead+0x1/0x120
> > > > >  make_task_dead from 0xc102ca80
> > > > > ---[ end Kernel panic - not syncing: Attempted to kill init!
> > > > > exitcode=0x00000007 ]---  

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

  reply	other threads:[~2023-05-29 11:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25  7:48 Boot failed after patch "mtd: rawnand: Support for sequential cache reads" Alexander Shiyan
2023-05-26 18:14 ` Miquel Raynal
2023-05-29  6:10   ` Alexander Shiyan
2023-05-29  8:12     ` Miquel Raynal
2023-05-29 10:33       ` Alexander Shiyan
2023-05-29 11:46         ` Miquel Raynal [this message]
2023-05-30 14:48           ` [EXT] " Bean Huo
2023-05-31  9:02             ` Alexander Shiyan
2023-06-01  7:37               ` Miquel Raynal
2023-06-01 16:55                 ` Bean Huo
2023-06-02  9:52                   ` Alexander Shiyan
2023-06-05  8:39                     ` Miquel Raynal
2023-06-05 15:45                       ` Bean Huo
2023-06-26  9:22                         ` Bean Huo
2023-07-03  9:16                           ` Alexander Shiyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230529134619.255d0b07@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=beanhuo@micron.com \
    --cc=eagle.alexander923@gmail.com \
    --cc=jaimeliao.tw@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox