Re: MTD: How to get actual image size from MTD partition

Hi Pintu,

On Fri, 20 Aug 2021 at 15:25, Pintu Agarwal [off-list ref] wrote:

On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal [off-list ref] wrote:

quoted

On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia
[off-list ref] wrote:

quoted

On Thu, 29 Jul 2021 at 08:45, Richard Weinberger [off-list ref] wrote:

quoted

Ezequiel,

----- Ursprüngliche Mail -----

quoted

[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.

quoted

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies