public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Boris Brezillon <bbrezillon@kernel.org>
To: "Marcin Krzemiński" <mar.krzeminski@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: VIRTIO iface in mtd
Date: Fri, 18 Jan 2019 21:44:55 +0100	[thread overview]
Message-ID: <20190118214455.18345232@bbrezillon> (raw)
In-Reply-To: <f53fe2ac-c1a1-1e64-1f4c-046b8e9daa2b@gmail.com>

On Fri, 18 Jan 2019 21:03:17 +0100
Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:

> >  
> >> My understanding is that this driver will use VIRTIO to communicate
> >> with Qemu. From Qemu side at the end there will be a file that will
> >> simulate NAND/NOR. Is it correct?  
> > That's my understanding, but I'm not really a virtio or qemu expert so
> > I might be wrong.
> >  
> >> What use cases do you have in mind for this?  
> > I have one in mind: simulate NAND (in particular MLC NAND) behavior in
> > a pseudo-realistic way to validate UBI/UBIFS code (or any other
> > FS/wear-leveling/FTL code) we might want to use on top of such devices  
> In this place my question is what we remove from emulation?
> I understand that communication layer is removed, however communication 
> protocol
> need t o stay? Eg. because NAND and OOB.

If by protocol you mean the fact that a NAND has an out-of-band and an
in-band area, then yes, we want to emulate that. What I meant by
"protocol" was the how you interact with a parallel or SPI NAND ("send
this opcode to do this or that"), and we definitely don't want to
emulate that part.

> 
> >
> > I'd also like to replace nandsim by this emulation approach. Indeed,
> > nandsim is emulating the parallel NAND protocol more than anything
> > else, which we don't really care about unless we need to test the raw
> > NAND framework (and I think there are better solutions to do that). On
> > the other hand, because nandsim tries to use the full raw NAND stack,
> > it's often hard to emulate real devices (ID-based detection does not
> > work for ONFI/JEDEC compatible devices). All of this makes nandsim a
> > poor choice when the user wants to emulate a NAND device to do
> > post-mortem analysis using a NAND dump.  
> This I need to understand better. If we eg. have NAND dump, do we care 
> with OOB or ECC,
> or not?

Yes we should. For the ECC part, it will be hard to emulate HW ECC
engine, but we can at least specify the layout in use on the board
(which OOB portions are used to store ECC bytes and which ones are
containing user data or bad block markers).

> 
> At the end I also need to add, that I understand NOR devices, but 
> unfortunately
> I have low experience with NANDs. This could lead to some misunderstands :(

We can help with that.

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

  reply	other threads:[~2019-01-18 20:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 20:16 VIRTIO iface in mtd Marcin Krzemiński
2019-01-17 20:46 ` Boris Brezillon
2019-01-18 20:03   ` Marcin Krzemiński
2019-01-18 20:44     ` Boris Brezillon [this message]
2019-01-18 21:25       ` Richard Weinberger
2019-01-20 19:49         ` Marcin Krzemiński
2019-01-21  8:07           ` Boris Brezillon
2019-01-21 18:14             ` Marcin Krzemiński
2019-01-21 18:46               ` Boris Brezillon

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=20190118214455.18345232@bbrezillon \
    --to=bbrezillon@kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mar.krzeminski@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    /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