LinuxLists.cc - [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

2021-08-01 23:47:06

Subject: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Hi Richard, and everyone else:

Browsing the internet for "JFFS2 mtd" results in tutorials, articles
and github.gists0 that point to mtdblock.

In fact, even the MTD wiki mentions that JFFS2
needs mtdblock to mount a rootfs:

http://www.linux-mtd.infradead.org/faq/jffs2.html

Moreover, I suspect there may be lots of users
that still believe mtdblock is somehow needed to
mount SquashFS.

I've taken a verbose route and added a pr_warn
warning if the devices are NAND. I don't think using
NAND without UBI is too wise, and given the amount
of outdated tutorials I believe some advertising
will help.

These patches are compile-tested only, as I don't
have devices ready to test, but I can undust some
boards and do some experiments if you think it's needed.

Oh, and PS: We also need to update the wiki.

Ezequiel Garcia (3):
mtdblock: Update old JFFS2 mention in Kconfig
mtdblock: Add comment about UBI block devices
mtdblock: Warn if the added for a NAND device

drivers/mtd/Kconfig | 10 ++++++----
drivers/mtd/mtdblock.c | 4 ++++
drivers/mtd/mtdblock_ro.c | 4 ++++
3 files changed, 14 insertions(+), 4 deletions(-)

--
2.32.0

2021-08-01 23:47:07

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig

JFFS2 can be mounted without 'mtdblock' since
a really, really long time. Some git-log
archaeology shows that in 2006 it was possible
to use 'root=' to mount a JFFS2 rootfs:

commit e9482b4374e2596e6f3f1ab30c4ea469f4ac6311
Author: Joern Engel <[email protected]>
Date: Tue May 30 14:25:46 2006 +0200

[MTD] Allow alternate JFFS2 mount variant for root filesystem.

With this patch, "root=mtd3" and "root=mtd:foo" work for a JFFS2 rootfs.

However, there are still plenty of tutorials that mention
mtdblock, so users are still taking this route. Update the Kconfig
to reflect this is no longer needed.

Signed-off-by: Ezequiel Garcia <[email protected]>
---
drivers/mtd/Kconfig | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 79a8ff542883..32bed6c63863 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -127,10 +127,9 @@ config MTD_BLOCK
on RAM chips in this manner. This block device is a user of MTD
devices performing that function.

- At the moment, it is also required for the Journalling Flash File
- System(s) to obtain a handle on the MTD device when it's mounted
- (although JFFS and JFFS2 don't actually use any of the functionality
- of the mtdblock device).
+ Note that mounting a JFFS2 filesystem doesn't require using mtdblock.
+ It's possible to mount a rootfs using the MTD device on the "root="
+ bootargs as "root=mtd2" or "root=mtd:name_of_device".

Later, it may be extended to perform read/erase/modify/write cycles
on flash chips to emulate a smaller block size. Needless to say,
--
2.32.0

2021-08-01 23:47:11

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 2/3] mtdblock: Add comment about UBI block devices

There is a surprisingly large number of tutorials
that suggest using mtdblock to mount SquashFS filesystems
on flash devices, including NAND devices.

Given this approach is suboptimal than using UBI, and given
the UBI block device layer was introduced many years ago
specifically with this use case in mind, add a small
comment inviting users and developers to consider UBI block.

Signed-off-by: Ezequiel Garcia <[email protected]>
---
drivers/mtd/Kconfig | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 32bed6c63863..91cdbbd44317 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -151,6 +151,9 @@ config MTD_BLOCK_RO
You do not need this option for use with the DiskOnChip devices. For
those, enable NFTL support (CONFIG_NFTL) instead.

+comment "Note that in some cases UBI block is preferred. See MTD_UBI_BLOCK."
+ depends on MTD_BLOCK || MTD_BLOCK_RO
+
config FTL
tristate "FTL (Flash Translation Layer) support"
depends on BLOCK
--
2.32.0

2021-08-01 23:47:20

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 3/3] mtdblock: Warn if the added for a NAND device

There is a surprisingly large number of tutorials
that suggest using mtdblock to mount SquashFS filesystems
on flash devices, including NAND devices.

This approach is suboptimal than using UBI. If the flash device
is NAND, this is specially true, due to wear leveling, bit-flips and
badblocks. In this case UBI is strongly preferred, so be nice to users
and print a warning suggesting to consider UBI block, if mtdblock
is added for a NAND device.

Signed-off-by: Ezequiel Garcia <[email protected]>

Untracked files not listed
---
drivers/mtd/mtdblock.c | 4 ++++
drivers/mtd/mtdblock_ro.c | 4 ++++
2 files changed, 8 insertions(+)

diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index b2d5ed1cbc94..7c02643f862f 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -332,6 +332,10 @@ static void mtdblock_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
if (!(mtd->flags & MTD_WRITEABLE))
dev->mbd.readonly = 1;

+ if (mtd_type_is_nand(mtd))
+ pr_warn("%s: MTD device '%s' is NAND, please consider using UBI block devices instead.\n",
+ tr->name, mtd->name);
+
if (add_mtd_blktrans_dev(&dev->mbd))
kfree(dev);
}
diff --git a/drivers/mtd/mtdblock_ro.c b/drivers/mtd/mtdblock_ro.c
index fb5dc89369de..a438e2f6089c 100644
--- a/drivers/mtd/mtdblock_ro.c
+++ b/drivers/mtd/mtdblock_ro.c
@@ -60,6 +60,10 @@ static void mtdblock_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
dev->tr = tr;
dev->readonly = 1;

+ if (mtd_type_is_nand(mtd))
+ pr_warn("%s: MTD device '%s' is NAND, please consider using UBI block devices instead.\n",
+ tr->name, mtd->name);
+
if (add_mtd_blktrans_dev(dev))
kfree(dev);
}
--
2.32.0

2021-08-01 23:47:40

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

2021-08-01 23:48:12

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig

2021-08-01 23:48:48

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 2/3] mtdblock: Add comment about UBI block devices

2021-08-01 23:49:05

by Ezequiel Garcia

[permalink] [raw]

Subject: [PATCH 3/3] mtdblock: Warn if the added for a NAND device

2021-08-07 00:09:56

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device

On Sun, 2021-08-01 at 23:45:09 UTC, Ezequiel Garcia wrote:
> There is a surprisingly large number of tutorials
> that suggest using mtdblock to mount SquashFS filesystems
> on flash devices, including NAND devices.
>
> This approach is suboptimal than using UBI. If the flash device
> is NAND, this is specially true, due to wear leveling, bit-flips and
> badblocks. In this case UBI is strongly preferred, so be nice to users
> and print a warning suggesting to consider UBI block, if mtdblock
> is added for a NAND device.
>
> Signed-off-by: Ezequiel Garcia <[email protected]>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.

Miquel

2021-08-07 00:10:15

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig

On Sun, 2021-08-01 at 23:45:07 UTC, Ezequiel Garcia wrote:
> JFFS2 can be mounted without 'mtdblock' since
> a really, really long time. Some git-log
> archaeology shows that in 2006 it was possible
> to use 'root=' to mount a JFFS2 rootfs:
>
> commit e9482b4374e2596e6f3f1ab30c4ea469f4ac6311
> Author: Joern Engel <[email protected]>
> Date: Tue May 30 14:25:46 2006 +0200
>
> [MTD] Allow alternate JFFS2 mount variant for root filesystem.
>
> With this patch, "root=mtd3" and "root=mtd:foo" work for a JFFS2 rootfs.
>
> However, there are still plenty of tutorials that mention
> mtdblock, so users are still taking this route. Update the Kconfig
> to reflect this is no longer needed.
>
> Signed-off-by: Ezequiel Garcia <[email protected]>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.

Miquel

2021-08-07 00:11:01

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 2/3] mtdblock: Add comment about UBI block devices

On Sun, 2021-08-01 at 23:45:08 UTC, Ezequiel Garcia wrote:
> There is a surprisingly large number of tutorials
> that suggest using mtdblock to mount SquashFS filesystems
> on flash devices, including NAND devices.
>
> Given this approach is suboptimal than using UBI, and given
> the UBI block device layer was introduced many years ago
> specifically with this use case in mind, add a small
> comment inviting users and developers to consider UBI block.
>
> Signed-off-by: Ezequiel Garcia <[email protected]>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.

Miquel

2021-08-17 16:31:50

by Ezequiel Garcia

[permalink] [raw]

Subject: Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device

Bonjour Miquel,

On Fri, 6 Aug 2021 at 17:05, Miquel Raynal <[email protected]> wrote:
>
> On Sun, 2021-08-01 at 23:45:09 UTC, Ezequiel Garcia wrote:
> > There is a surprisingly large number of tutorials
> > that suggest using mtdblock to mount SquashFS filesystems
> > on flash devices, including NAND devices.
> >
> > This approach is suboptimal than using UBI. If the flash device
> > is NAND, this is specially true, due to wear leveling, bit-flips and
> > badblocks. In this case UBI is strongly preferred, so be nice to users
> > and print a warning suggesting to consider UBI block, if mtdblock
> > is added for a NAND device.
> >
> > Signed-off-by: Ezequiel Garcia <[email protected]>
>
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
>

Any chance you respin this one?

It appears somehow this made its way to the patch:
"Untracked files not listed" sorry about that -- could you remove it?

While there, you can fix the typo in the commit title:
"mtdblock: Warn if the added for a NAND device" -> "mtdblock: Warn if
added for a NAND device"

Thanks a lot,
Ezequiel

2021-08-17 16:50:28

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device

Hi Ezequiel,

Ezequiel Garcia <[email protected]> wrote on Tue, 17 Aug
2021 13:27:54 -0300:

> Bonjour Miquel,
>
> On Fri, 6 Aug 2021 at 17:05, Miquel Raynal <[email protected]> wrote:
> >
> > On Sun, 2021-08-01 at 23:45:09 UTC, Ezequiel Garcia wrote:
> > > There is a surprisingly large number of tutorials
> > > that suggest using mtdblock to mount SquashFS filesystems
> > > on flash devices, including NAND devices.
> > >
> > > This approach is suboptimal than using UBI. If the flash device
> > > is NAND, this is specially true, due to wear leveling, bit-flips and
> > > badblocks. In this case UBI is strongly preferred, so be nice to users
> > > and print a warning suggesting to consider UBI block, if mtdblock
> > > is added for a NAND device.
> > >
> > > Signed-off-by: Ezequiel Garcia <[email protected]>
> >
> > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
> >
>
> Any chance you respin this one?
>
> It appears somehow this made its way to the patch:
> "Untracked files not listed" sorry about that -- could you remove it?

Yeah no problem about that, it happens ;)

> While there, you can fix the typo in the commit title:
> "mtdblock: Warn if the added for a NAND device" -> "mtdblock: Warn if
> added for a NAND device"

Done as well.

Cheers!
Miquèl

2021-10-26 20:19:54

by Trevor Woerner

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> Hi Richard, and everyone else:
>
> Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> and github.gists0 that point to mtdblock.
>
> In fact, even the MTD wiki mentions that JFFS2
> needs mtdblock to mount a rootfs:
>
> http://www.linux-mtd.infradead.org/faq/jffs2.html
>
> Moreover, I suspect there may be lots of users
> that still believe mtdblock is somehow needed to
> mount SquashFS.
>
> I've taken a verbose route and added a pr_warn
> warning if the devices are NAND. I don't think using
> NAND without UBI is too wise, and given the amount
> of outdated tutorials I believe some advertising
> will help.

Not all NAND partitions on a device will contain linux root filesystems. For a
linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
print out for each and every NAND partition:

[ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
[ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
[ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI block devices instead.
[ 0.933334] 0x000000020000-0x000000080000 : "uboot"
[ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI block devices instead.
[ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
[ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using UBI block devices instead.
[ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
[ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using UBI block devices instead.
[ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
[ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using UBI block devices instead.
[ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
[ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using UBI block devices instead.
[ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
[ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using UBI block devices instead.
[ 1.113335] 0x000001000000-0x000020000000 : "mender"
[ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI block devices instead.

NAND tends to be something found on older devices, the firmware/bootloaders
of older devices couldn't possibly understand UBI/UBIFS so many of these
partitions need be "raw" partitions, or use something that predates UBI.

Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
yet I got the same "please use UBI" message as all the others (lol)

I'm specifying my partitions in DT with:

partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
};

which is why, I assume, I'm getting these messages. Is there a UBI-friendly
way to define them to avoid these messages?

Best regards,
Trevor

2021-10-27 07:20:36

by Richard Weinberger

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Trevor,

----- Ursprüngliche Mail -----
> Von: "Trevor Woerner" <[email protected]>
> An: "Ezequiel Garcia" <[email protected]>
> CC: "linux-mtd" <[email protected]>, "linux-kernel" <[email protected]>, "richard"
> <[email protected]>, "Miquel Raynal" <[email protected]>, "Vignesh Raghavendra" <[email protected]>
> Gesendet: Dienstag, 26. Oktober 2021 17:03:50
> Betreff: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

> On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
>> Hi Richard, and everyone else:
>>
>> Browsing the internet for "JFFS2 mtd" results in tutorials, articles
>> and github.gists0 that point to mtdblock.
>>
>> In fact, even the MTD wiki mentions that JFFS2
>> needs mtdblock to mount a rootfs:
>>
>> http://www.linux-mtd.infradead.org/faq/jffs2.html
>>
>> Moreover, I suspect there may be lots of users
>> that still believe mtdblock is somehow needed to
>> mount SquashFS.
>>
>> I've taken a verbose route and added a pr_warn
>> warning if the devices are NAND. I don't think using
>> NAND without UBI is too wise, and given the amount
>> of outdated tutorials I believe some advertising
>> will help.
>
> Not all NAND partitions on a device will contain linux root filesystems. For a
> linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> print out for each and every NAND partition:
>
> [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI
> block devices instead.
> [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI
> block devices instead.
> [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using
> UBI block devices instead.
> [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using
> UBI block devices instead.
> [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using
> UBI block devices instead.
> [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using
> UBI block devices instead.
> [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using
> UBI block devices instead.
> [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI
> block devices instead.
>
> NAND tends to be something found on older devices, the firmware/bootloaders
> of older devices couldn't possibly understand UBI/UBIFS so many of these
> partitions need be "raw" partitions, or use something that predates UBI.
>
> Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> yet I got the same "please use UBI" message as all the others (lol)
>
> I'm specifying my partitions in DT with:
>
> partitions {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> };
>
> which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> way to define them to avoid these messages?

Hmm, maybe it makes sense to advertise it only once and not for each mtdblock device.

Thanks,
//richard

2021-10-28 13:33:52

by Trevor Woerner

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

On Tue 2021-10-26 @ 09:01:32 PM, Richard Weinberger wrote:
> Trevor,
>
> ----- Ursprüngliche Mail -----
> > Von: "Trevor Woerner" <[email protected]>
> > An: "Ezequiel Garcia" <[email protected]>
> > CC: "linux-mtd" <[email protected]>, "linux-kernel" <[email protected]>, "richard"
> > <[email protected]>, "Miquel Raynal" <[email protected]>, "Vignesh Raghavendra" <[email protected]>
> > Gesendet: Dienstag, 26. Oktober 2021 17:03:50
> > Betreff: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
>
> > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> >> Hi Richard, and everyone else:
> >>
> >> Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> >> and github.gists0 that point to mtdblock.
> >>
> >> In fact, even the MTD wiki mentions that JFFS2
> >> needs mtdblock to mount a rootfs:
> >>
> >> http://www.linux-mtd.infradead.org/faq/jffs2.html
> >>
> >> Moreover, I suspect there may be lots of users
> >> that still believe mtdblock is somehow needed to
> >> mount SquashFS.
> >>
> >> I've taken a verbose route and added a pr_warn
> >> warning if the devices are NAND. I don't think using
> >> NAND without UBI is too wise, and given the amount
> >> of outdated tutorials I believe some advertising
> >> will help.
> >
> > Not all NAND partitions on a device will contain linux root filesystems. For a
> > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > print out for each and every NAND partition:
> >
> > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI
> > block devices instead.
> > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI
> > block devices instead.
> > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using
> > UBI block devices instead.
> > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using
> > UBI block devices instead.
> > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using
> > UBI block devices instead.
> > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using
> > UBI block devices instead.
> > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using
> > UBI block devices instead.
> > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI
> > block devices instead.
> >
> > NAND tends to be something found on older devices, the firmware/bootloaders
> > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > partitions need be "raw" partitions, or use something that predates UBI.
> >
> > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > yet I got the same "please use UBI" message as all the others (lol)
> >
> > I'm specifying my partitions in DT with:
> >
> > partitions {
> > compatible = "fixed-partitions";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > };
> >
> > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > way to define them to avoid these messages?
>
> Hmm, maybe it makes sense to advertise it only once and not for each mtdblock device.

Are there known bugs or issues using ubi/jffs2/squashfs on top of mtdblock? Is
mtdblock being deprecated? If so I could certainly understand warning users of
the situation.

Is there a safe/easy way to update an older device in a way that wipes
the entire flash while running from flash? If not then having the kernel
perpetually advertising that I'm not using my flash a certain way isn't very
useful, especially if there aren't any underlying reasons why my usage isn't
valid.

2021-11-09 19:36:04

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Hi Trevor, Ezequiel,

[email protected] wrote on Thu, 28 Oct 2021 09:31:19 -0400:

> On Tue 2021-10-26 @ 09:01:32 PM, Richard Weinberger wrote:
> > Trevor,
> >
> > ----- Ursprüngliche Mail -----
> > > Von: "Trevor Woerner" <[email protected]>
> > > An: "Ezequiel Garcia" <[email protected]>
> > > CC: "linux-mtd" <[email protected]>, "linux-kernel" <[email protected]>, "richard"
> > > <[email protected]>, "Miquel Raynal" <[email protected]>, "Vignesh Raghavendra" <[email protected]>
> > > Gesendet: Dienstag, 26. Oktober 2021 17:03:50
> > > Betreff: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
> >
> > > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > >> Hi Richard, and everyone else:
> > >>
> > >> Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > >> and github.gists0 that point to mtdblock.
> > >>
> > >> In fact, even the MTD wiki mentions that JFFS2
> > >> needs mtdblock to mount a rootfs:
> > >>
> > >> http://www.linux-mtd.infradead.org/faq/jffs2.html
> > >>
> > >> Moreover, I suspect there may be lots of users
> > >> that still believe mtdblock is somehow needed to
> > >> mount SquashFS.
> > >>
> > >> I've taken a verbose route and added a pr_warn
> > >> warning if the devices are NAND. I don't think using
> > >> NAND without UBI is too wise, and given the amount
> > >> of outdated tutorials I believe some advertising
> > >> will help.
> > >
> > > Not all NAND partitions on a device will contain linux root filesystems. For a
> > > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > > print out for each and every NAND partition:
> > >
> > > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI
> > > block devices instead.
> > > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI
> > > block devices instead.
> > > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI
> > > block devices instead.
> > >
> > > NAND tends to be something found on older devices, the firmware/bootloaders
> > > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > > partitions need be "raw" partitions, or use something that predates UBI.
> > >
> > > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > > yet I got the same "please use UBI" message as all the others (lol)
> > >
> > > I'm specifying my partitions in DT with:
> > >
> > > partitions {
> > > compatible = "fixed-partitions";
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > > };
> > >
> > > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > > way to define them to avoid these messages?
> >
> > Hmm, maybe it makes sense to advertise it only once and not for each mtdblock device.
>
> Are there known bugs or issues using ubi/jffs2/squashfs on top of mtdblock? Is
> mtdblock being deprecated? If so I could certainly understand warning users of
> the situation.

This message is not actually directed to people with old setups, but
more to people creating new setups. I don't care if the loglevel is
lowered to info, if you think this is better than a warning.

Can someone please send a fix to display this message once?

Thanks,
Miquèl

2021-11-09 23:30:38

by Daniel Golle

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

On Thu, Oct 28, 2021 at 09:31:19AM -0400, Trevor Woerner wrote:
> On Tue 2021-10-26 @ 09:01:32 PM, Richard Weinberger wrote:
> > Trevor,
> >
> > ----- Urspr?ngliche Mail -----
> > > Von: "Trevor Woerner" <[email protected]>
> > > An: "Ezequiel Garcia" <[email protected]>
> > > CC: "linux-mtd" <[email protected]>, "linux-kernel" <[email protected]>, "richard"
> > > <[email protected]>, "Miquel Raynal" <[email protected]>, "Vignesh Raghavendra" <[email protected]>
> > > Gesendet: Dienstag, 26. Oktober 2021 17:03:50
> > > Betreff: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
> >
> > > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > >> Hi Richard, and everyone else:
> > >>
> > >> Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > >> and github.gists0 that point to mtdblock.
> > >>
> > >> In fact, even the MTD wiki mentions that JFFS2
> > >> needs mtdblock to mount a rootfs:
> > >>
> > >> http://www.linux-mtd.infradead.org/faq/jffs2.html
> > >>
> > >> Moreover, I suspect there may be lots of users
> > >> that still believe mtdblock is somehow needed to
> > >> mount SquashFS.
> > >>
> > >> I've taken a verbose route and added a pr_warn
> > >> warning if the devices are NAND. I don't think using
> > >> NAND without UBI is too wise, and given the amount
> > >> of outdated tutorials I believe some advertising
> > >> will help.
> > >
> > > Not all NAND partitions on a device will contain linux root filesystems. For a
> > > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > > print out for each and every NAND partition:
> > >
> > > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI
> > > block devices instead.
> > > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI
> > > block devices instead.
> > > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using
> > > UBI block devices instead.
> > > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI
> > > block devices instead.
> > >
> > > NAND tends to be something found on older devices, the firmware/bootloaders
> > > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > > partitions need be "raw" partitions, or use something that predates UBI.
> > >
> > > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > > yet I got the same "please use UBI" message as all the others (lol)
> > >
> > > I'm specifying my partitions in DT with:
> > >
> > > partitions {
> > > compatible = "fixed-partitions";
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > > };
> > >
> > > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > > way to define them to avoid these messages?
> >
> > Hmm, maybe it makes sense to advertise it only once and not for each mtdblock device.
>
> Are there known bugs or issues using ubi/jffs2/squashfs on top of mtdblock? Is
> mtdblock being deprecated? If so I could certainly understand warning users of
> the situation.

In case of NAND flash, using mtdblock is generally not such a good idea
as you miss out on features which are essential for the vitality of the
flash (wear-leveling and such).

UBI works on top of mtd device, it cannot work on top of mtdblock.

For JFFS2 we got a hack which allows mounting using the mtdblock device
but actually also uses the mtd device under the hood (being able to
mount using mtdblock is a pure convenience feature for easier
compatibility with userspace tools).

So generally, when using mtdblock on top of NAND flash you are doing
less-than-optimal in every case.

>
> Is there a safe/easy way to update an older device in a way that wipes
> the entire flash while running from flash? If not then having the kernel
> perpetually advertising that I'm not using my flash a certain way isn't very
> useful, especially if there aren't any underlying reasons why my usage isn't
> valid.

There are very good reasons for not using mtdblock on NAND flash, such
as the complete lack of wear-leveling (which is mandatory if you want
that flash to survive a couple of write cycles).

Legacy setups are sometimes not easy to migrate, to do things properly
you may have to replace or modify the way the device loads the kernel
from flash during boot, like I did for a recent SPI-NAND based WiFi
router:
https://github.com/dangowrt/linksys-e8450-openwrt-installer

2021-11-12 13:54:54

by Ezequiel Garcia

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Hi Trevor,

I am not reachable at ezequiel at collabora.com, so I missed this
thread. Sorry about the delay, replying.

On Tue, 26 Oct 2021 at 12:05, Trevor Woerner <[email protected]> wrote:
>
> On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > Hi Richard, and everyone else:
> >
> > Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > and github.gists0 that point to mtdblock.
> >
> > In fact, even the MTD wiki mentions that JFFS2
> > needs mtdblock to mount a rootfs:
> >
> > http://www.linux-mtd.infradead.org/faq/jffs2.html
> >
> > Moreover, I suspect there may be lots of users
> > that still believe mtdblock is somehow needed to
> > mount SquashFS.
> >
> > I've taken a verbose route and added a pr_warn
> > warning if the devices are NAND. I don't think using
> > NAND without UBI is too wise, and given the amount
> > of outdated tutorials I believe some advertising
> > will help.
>
> Not all NAND partitions on a device will contain linux root filesystems. For a
> linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> print out for each and every NAND partition:
>
> [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI block devices instead.
> [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI block devices instead.
> [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using UBI block devices instead.
> [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using UBI block devices instead.
> [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using UBI block devices instead.
> [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using UBI block devices instead.
> [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using UBI block devices instead.
> [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI block devices instead.
>
> NAND tends to be something found on older devices, the firmware/bootloaders
> of older devices couldn't possibly understand UBI/UBIFS so many of these
> partitions need be "raw" partitions, or use something that predates UBI.
>
> Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> yet I got the same "please use UBI" message as all the others (lol)
>
> I'm specifying my partitions in DT with:
>
> partitions {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> };
>
> which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> way to define them to avoid these messages?
>

I feel the messages are actually helping you. You should not have mtdblock
on any of these MTD devices, if I understood correctly, since you are not
mounting a filesystem on any of them.

Just disable MTDBLOCK on your build and you will be good to go.

I am inclined to just leave the warnings, although they look spammy,
precisely to help catch this mis-setups.

Thanks,
Ezequiel

2022-01-21 21:13:47

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Hi Ezequiel,

[email protected] wrote on Fri, 12 Nov 2021 10:54:36 -0300:

> Hi Trevor,
>
> I am not reachable at ezequiel at collabora.com, so I missed this
> thread. Sorry about the delay, replying.
>
> On Tue, 26 Oct 2021 at 12:05, Trevor Woerner <[email protected]> wrote:
> >
> > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > > Hi Richard, and everyone else:
> > >
> > > Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > > and github.gists0 that point to mtdblock.
> > >
> > > In fact, even the MTD wiki mentions that JFFS2
> > > needs mtdblock to mount a rootfs:
> > >
> > > http://www.linux-mtd.infradead.org/faq/jffs2.html
> > >
> > > Moreover, I suspect there may be lots of users
> > > that still believe mtdblock is somehow needed to
> > > mount SquashFS.
> > >
> > > I've taken a verbose route and added a pr_warn
> > > warning if the devices are NAND. I don't think using
> > > NAND without UBI is too wise, and given the amount
> > > of outdated tutorials I believe some advertising
> > > will help.
> >
> > Not all NAND partitions on a device will contain linux root filesystems. For a
> > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > print out for each and every NAND partition:
> >
> > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI block devices instead.
> > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI block devices instead.
> > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using UBI block devices instead.
> > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using UBI block devices instead.
> > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using UBI block devices instead.
> > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using UBI block devices instead.
> > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using UBI block devices instead.
> > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI block devices instead.
> >
> > NAND tends to be something found on older devices, the firmware/bootloaders
> > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > partitions need be "raw" partitions, or use something that predates UBI.
> >
> > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > yet I got the same "please use UBI" message as all the others (lol)
> >
> > I'm specifying my partitions in DT with:
> >
> > partitions {
> > compatible = "fixed-partitions";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > };
> >
> > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > way to define them to avoid these messages?
> >
>
> I feel the messages are actually helping you. You should not have mtdblock
> on any of these MTD devices, if I understood correctly, since you are not
> mounting a filesystem on any of them.
>
> Just disable MTDBLOCK on your build and you will be good to go.
>
> I am inclined to just leave the warnings, although they look spammy,
> precisely to help catch this mis-setups.

I keep getting complaints about these messages because they are
spawned several times in a boot (each device or partition, I don't
recall) while mtdblock is not even used. I understand it would be best
to have it disabled in this case but could we find a way to be less
invasive?

Thanks,
Miquèl

2022-01-21 21:17:08

by Ezequiel Garcia

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

On Thu, 20 Jan 2022 at 06:39, Miquel Raynal <[email protected]> wrote:
>
> Hi Ezequiel,
>
> [email protected] wrote on Fri, 12 Nov 2021 10:54:36 -0300:
>
> > Hi Trevor,
> >
> > I am not reachable at ezequiel at collabora.com, so I missed this
> > thread. Sorry about the delay, replying.
> >
> > On Tue, 26 Oct 2021 at 12:05, Trevor Woerner <[email protected]> wrote:
> > >
> > > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > > > Hi Richard, and everyone else:
> > > >
> > > > Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > > > and github.gists0 that point to mtdblock.
> > > >
> > > > In fact, even the MTD wiki mentions that JFFS2
> > > > needs mtdblock to mount a rootfs:
> > > >
> > > > http://www.linux-mtd.infradead.org/faq/jffs2.html
> > > >
> > > > Moreover, I suspect there may be lots of users
> > > > that still believe mtdblock is somehow needed to
> > > > mount SquashFS.
> > > >
> > > > I've taken a verbose route and added a pr_warn
> > > > warning if the devices are NAND. I don't think using
> > > > NAND without UBI is too wise, and given the amount
> > > > of outdated tutorials I believe some advertising
> > > > will help.
> > >
> > > Not all NAND partitions on a device will contain linux root filesystems. For a
> > > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > > print out for each and every NAND partition:
> > >
> > > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI block devices instead.
> > > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI block devices instead.
> > > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using UBI block devices instead.
> > > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using UBI block devices instead.
> > > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using UBI block devices instead.
> > > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using UBI block devices instead.
> > > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using UBI block devices instead.
> > > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI block devices instead.
> > >
> > > NAND tends to be something found on older devices, the firmware/bootloaders
> > > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > > partitions need be "raw" partitions, or use something that predates UBI.
> > >
> > > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > > yet I got the same "please use UBI" message as all the others (lol)
> > >
> > > I'm specifying my partitions in DT with:
> > >
> > > partitions {
> > > compatible = "fixed-partitions";
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > > };
> > >
> > > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > > way to define them to avoid these messages?
> > >
> >
> > I feel the messages are actually helping you. You should not have mtdblock
> > on any of these MTD devices, if I understood correctly, since you are not
> > mounting a filesystem on any of them.
> >
> > Just disable MTDBLOCK on your build and you will be good to go.
> >
> > I am inclined to just leave the warnings, although they look spammy,
> > precisely to help catch this mis-setups.
>
> I keep getting complaints about these messages because they are
> spawned several times in a boot (each device or partition, I don't
> recall) while mtdblock is not even used. I understand it would be best
> to have it disabled in this case but could we find a way to be less
> invasive?
>

If we still want to keep the warning, I suppose that moving these warnings
to blktrans_open should help ... unless the block device open ends
up being called anyway, and still gets spammy.

The alternative is removing them, perhaps adding a message to config MTD_BLOCK
about UBI blocks?

Thanks,
Ezequiel

2022-01-21 21:37:05

by Miquel Raynal

[permalink] [raw]

Subject: Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block

Hi Ezequiel,

[email protected] wrote on Thu, 20 Jan 2022 07:26:09 -0300:

> On Thu, 20 Jan 2022 at 06:39, Miquel Raynal <[email protected]> wrote:
> >
> > Hi Ezequiel,
> >
> > [email protected] wrote on Fri, 12 Nov 2021 10:54:36 -0300:
> >
> > > Hi Trevor,
> > >
> > > I am not reachable at ezequiel at collabora.com, so I missed this
> > > thread. Sorry about the delay, replying.
> > >
> > > On Tue, 26 Oct 2021 at 12:05, Trevor Woerner <[email protected]> wrote:
> > > >
> > > > On Sun 2021-08-01 @ 08:45:02 PM, Ezequiel Garcia wrote:
> > > > > Hi Richard, and everyone else:
> > > > >
> > > > > Browsing the internet for "JFFS2 mtd" results in tutorials, articles
> > > > > and github.gists0 that point to mtdblock.
> > > > >
> > > > > In fact, even the MTD wiki mentions that JFFS2
> > > > > needs mtdblock to mount a rootfs:
> > > > >
> > > > > http://www.linux-mtd.infradead.org/faq/jffs2.html
> > > > >
> > > > > Moreover, I suspect there may be lots of users
> > > > > that still believe mtdblock is somehow needed to
> > > > > mount SquashFS.
> > > > >
> > > > > I've taken a verbose route and added a pr_warn
> > > > > warning if the devices are NAND. I don't think using
> > > > > NAND without UBI is too wise, and given the amount
> > > > > of outdated tutorials I believe some advertising
> > > > > will help.
> > > >
> > > > Not all NAND partitions on a device will contain linux root filesystems. For a
> > > > linux root filesystem perhaps using UBI/UBIFS is preferred, yet these messages
> > > > print out for each and every NAND partition:
> > > >
> > > > [ 0.900827] Creating 8 MTD partitions on "nxp_lpc3220_slc":
> > > > [ 0.906431] 0x000000000000-0x000000020000 : "bootrom"
> > > > [ 0.913523] mtdblock: MTD device 'bootrom' is NAND, please consider using UBI block devices instead.
> > > > [ 0.933334] 0x000000020000-0x000000080000 : "uboot"
> > > > [ 0.940439] mtdblock: MTD device 'uboot' is NAND, please consider using UBI block devices instead.
> > > > [ 0.963322] 0x000000080000-0x000000440000 : "fbkernel"
> > > > [ 0.970655] mtdblock: MTD device 'fbkernel' is NAND, please consider using UBI block devices instead.
> > > > [ 0.993361] 0x000000440000-0x000000920000 : "fbrootfs"
> > > > [ 1.000725] mtdblock: MTD device 'fbrootfs' is NAND, please consider using UBI block devices instead.
> > > > [ 1.023315] 0x000000920000-0x000000ce0000 : "c_kernel"
> > > > [ 1.030722] mtdblock: MTD device 'c_kernel' is NAND, please consider using UBI block devices instead.
> > > > [ 1.053444] 0x000000ce0000-0x000000d00000 : "c__atags"
> > > > [ 1.060742] mtdblock: MTD device 'c__atags' is NAND, please consider using UBI block devices instead.
> > > > [ 1.083349] 0x000000d00000-0x000001000000 : "c_rootfs"
> > > > [ 1.090702] mtdblock: MTD device 'c_rootfs' is NAND, please consider using UBI block devices instead.
> > > > [ 1.113335] 0x000001000000-0x000020000000 : "mender"
> > > > [ 1.131627] mtdblock: MTD device 'mender' is NAND, please consider using UBI block devices instead.
> > > >
> > > > NAND tends to be something found on older devices, the firmware/bootloaders
> > > > of older devices couldn't possibly understand UBI/UBIFS so many of these
> > > > partitions need be "raw" partitions, or use something that predates UBI.
> > > >
> > > > Ironically my "mender" partition contains a UBI (with multiple UBIFSes inside)
> > > > yet I got the same "please use UBI" message as all the others (lol)
> > > >
> > > > I'm specifying my partitions in DT with:
> > > >
> > > > partitions {
> > > > compatible = "fixed-partitions";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > mtd0@0 { label = "bootrom"; reg = <0x00000000 0x00020000>; };
> > > > mtd1@20000 { label = "uboot"; reg = <0x00020000 0x00060000>; };
> > > > mtd2@80000 { label = "fbkernel"; reg = <0x00080000 0x003c0000>; };
> > > > mtd3@440000 { label = "fbrootfs"; reg = <0x00440000 0x004e0000>; };
> > > > mtd4@920000 { label = "c_kernel"; reg = <0x00920000 0x003c0000>; };
> > > > mtd5@ce0000 { label = "c__atags"; reg = <0x00ce0000 0x00020000>; };
> > > > mtd6@d00000 { label = "c_rootfs"; reg = <0x00d00000 0x00300000>; };
> > > > mtd7@1000000 { label = "mender"; reg = <0x01000000 0x1f000000>; };
> > > > };
> > > >
> > > > which is why, I assume, I'm getting these messages. Is there a UBI-friendly
> > > > way to define them to avoid these messages?
> > > >
> > >
> > > I feel the messages are actually helping you. You should not have mtdblock
> > > on any of these MTD devices, if I understood correctly, since you are not
> > > mounting a filesystem on any of them.
> > >
> > > Just disable MTDBLOCK on your build and you will be good to go.
> > >
> > > I am inclined to just leave the warnings, although they look spammy,
> > > precisely to help catch this mis-setups.
> >
> > I keep getting complaints about these messages because they are
> > spawned several times in a boot (each device or partition, I don't
> > recall) while mtdblock is not even used. I understand it would be best
> > to have it disabled in this case but could we find a way to be less
> > invasive?
> >
>
> If we still want to keep the warning, I suppose that moving these warnings
> to blktrans_open should help ... unless the block device open ends
> up being called anyway, and still gets spammy.

This solution is my favorite, unless as you say it's opened anyway.

> The alternative is removing them, perhaps adding a message to config MTD_BLOCK
> about UBI blocks?

That's a fallback solution indeed.

Thanks,
Miquèl