All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Joachim Wiberg <troglobit@gmail.com>
Cc: linux-mtd@lists.infradead.org, Joern Engel <joern@lazybastard.org>
Subject: Re: [RFC PATCH 1/1] mtd: block2mtd: add support for an optional custom MTD label
Date: Mon, 4 Oct 2021 17:39:38 +0200	[thread overview]
Message-ID: <20211004173938.12dc2d9a@xps13> (raw)
In-Reply-To: <87h7e32yhz.fsf@gmail.com>

Hi Joachim,

troglobit@gmail.com wrote on Wed, 29 Sep 2021 17:27:20 +0200:

> Hi Miquel!
> 
> On Tue, Sep 28, 2021 at 18:05, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > Hi Joachim,
> > troglobit@gmail.com wrote on Tue, 28 Sep 2021 17:49:38 +0200:  
> >> This patch adds support for an optional MTD label for mtd2block emulated
> >> MTD devices.  Useful when, e.g. testing device images using Qemu.  The
> >> following /etc/fstab line in can then be used to mount a file system
> >> regardless of the actual MTD partition number:
> >> 
> >>     mtd:Config  /mnt    jffs2   noatime,nodiratime      0    0
> >> 
> >> Kernel command line syntax:
> >> 
> >>     block2mtd.block2mtd=/dev/sda,,Config
> >> 
> >> The ',,' is the optional erase_size, which like before this patch,
> >> defaults to PAGE_SIZE when omitted.  
> > We already have a label property that can be added in the DT, isn't
> > it enough?  
> 
> Unless I'm missing something, no.  Sorry if if the description was a bit
> unclear.  Let me try expanding on it a bit.
> 
> The block2mtd driver is used a lot when emulating proper MTDs, I'm sure
> we are not alone in building system images that a flashed to an MTD
> device, which we want to be able to test in Qemu before deploying.
> 
> So what we typically do is have a read-only rootfs (squashfs) on one
> partition, and another for config data that uses overlayfs to get a
> writable /etc, for instance.  This is a reduced example, and the order
> of parititions sometimes differ, so we use parition labels. When we test
> in Qemu there's only the automatic DTB from Qemu itself that's injected,
> e.g.
> 
>   qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic       \
> 	-kernel Image -initrd rootfs.img -append               \
>           "root=/dev/ram block2mtd.block2mtd=/dev/vda"         \
>         -drive file=config.img,if=none,format=raw,id=hd0       \
>         -device virtio-blk-device,drive=hd0
> 
> With the default blockt2mtd args we convert the emulated disk to be
> used as an MTD partition, but the name we get in Linux is not the
> name we have in our /etc/fstab on a real target.
> 
>   # cat /proc/mtd 
>   dev:    size   erasesize  name
>   mtd0: 00f00000 00001000 "block2mtd: /dev/vda"
> 
> With the patch we can align the two cases; the embedded system and the
> emulated one, by using the same paritition label.  I.e., with the patch
> and the new argument to the kernel cmdline:
> 
>   qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic       \
> 	-kernel Image -initrd rootfs.img -append               \
>           "root=/dev/ram block2mtd.block2mtd=/dev/vda,,Config" \
>         -drive file=config.img,if=none,format=raw,id=hd0       \
>         -device virtio-blk-device,drive=hd0
> 
> Linux gives the emulated MTD the same partition name we use in the
> real embedded system:
> 
>   # cat /proc/mtd 
>   dev:    size   erasesize  name
>   mtd0: 00f00000 00001000 "Config"

I don't know this portion of the code very well, but indeed if this is
something only declared on the cmdline I understand the request.

Thanks,
Miquèl

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

      reply	other threads:[~2021-10-04 15:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 15:49 [RFC PATCH 1/1] mtd: block2mtd: add support for an optional custom MTD label Joachim Wiberg
2021-09-28 16:05 ` Miquel Raynal
2021-09-29 15:27   ` Joachim Wiberg
2021-10-04 15:39     ` Miquel Raynal [this message]

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=20211004173938.12dc2d9a@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=joern@lazybastard.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=troglobit@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.