MTD: How to get actual image size from MTD partition

[Ezequiel Garcia]

Hi Pintu,

On Fri, 20 Aug 2021 at 15:25, Pintu Agarwal <pintu.ping at gmail.com> wrote:
>
> On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal <pintu.ping at gmail.com> wrote:
> >
> > On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia
> > <ezequiel at vanguardiasur.com.ar> wrote:
> > >
> > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger <richard at nod.at> wrote:
> > > >
> > > > Ezequiel,
> > > >
> > > > ----- Ursprüngliche Mail -----
> > > > > [snip]
> > > > >
> > > > > Ouch, so surprised that after all these years someone is doing squashfs/mtdblock
> > > > > instead of using ubiblock :-)
> > > > >
> > > > > Can we patch either Kconfig or add some warn_once on mtdblock
> > > > > usage, suggesting to use ubiblock instead?
> > > >
> > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch?
> > > > A warning is too much since on some tiny embedded system with NOR flash mtdblock is still
> > > > a good choice.
> > > > ubiblock is mostly useful for NAND flash.
> > > >
> > > > > I remember there was still some use case(s) for mtdblock but I can't remember
> > > > > now what was it, perhaps we should document the expectations?
> > > > > (Is that for JFFS2 to mount?)
> > > >
> > > > a long time ago mount didn't accept character devices, so you had to pass mtdblockX to mount
> > > > JFFS2.
> > > > This limitation is gone.
> > > >
>
> Hi,
>
> Just a further follow-up on this discussion.
> Whether to use /dev/mtdblock or /dev/ubiblock for rootfs (squashfs)
> mounting during boot.
>
> As suggested here:
> Instead of using this in kernel command line:
> [    0.000000] Kernel command line: ... rootfstype=squashfs
> root=/dev/mtdblock44 ubi.mtd=40,0,30 ...
>
> I used this:
> [    0.000000] Kernel command line: ... rootfstype=squashfs
> ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 ...
>
> The device is booting fine with ubiblock as well.
> But, per say, I could not find any visible difference.
> I just observed a slight improvement in boot time, but I need to
> double-check on this, with few more reboot cycles.
>

That's a very good thing, it means we offered you a smooth transition :-)

> Apart from this what are the other visible benefits of using ubiblock
> which can be explained to be management or internal team ?
> I could not find any documentation explaining the difference, except this one:
> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock
>

I'm not a flash expert here. In any case, you are expected to do your own
research (just like we all did), design your own setup matching
your use-case, design tests based on your workload and access patterns, etc.

There are presentations on YouTube which discuss UBI, UBIFS and
NAND-based designs on Linux, as well as white papers discussing
NAND flashes challenges.

Having said that...

When you use UBI block, you are accessing the flash via the UBI layer.
This is IMO the best way to design your system, since UBI addresses
wear leveling and bad blocks, and offers atomic updates.

In other words, IMO it's best to expose the NAND through UBI
for both read-only and read-write access, using a single UBI device,
and then creating UBI volumes as needed. This will allow UBI
to spread wear leveling across the whole device, which is expected
to increase the flash lifetime.

For instance, just as some silly example, you could have something like this:

                               | RootFS SquashFS  |
                               | UBI block        | UBIFS User R-W area
------------------------------------------------------------------------
Kernel A | Kernel B | RootFS A | RootFS B         | User
------------------------------------------------------------------------
                                 UBIX
------------------------------------------------------------------------
                                 /dev/mtdX

This setup allows safe kernel and rootfs upgrading. The RootFS is read-only
via SquashFS and there's a read-write user area. UBI is supporting all
the volumes, handling bad blocks and wear leveling.

> Can someone also point me to the respective driver code in case of
> using /dev/mtdblock and /dev/ubiblock ?
> Apart from theory I also want to check the impact at the code level..
>

You can find all the UBI code in drivers/mtd/ubi of course. The differences
between mtdblock and ubiblock are huge: one goes directly to the flash,
and the other uses UBI.

Good luck!
Ezequiel