* [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
@ 2021-08-01 23:45 Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
` (7 more replies)
0 siblings, 8 replies; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
` (6 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <joern@wh.fh-wedel.de>
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 <ezequiel@collabora.com>
---
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/3] mtdblock: Add comment about UBI block devices
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
` (5 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <ezequiel@collabora.com>
---
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/3] mtdblock: Warn if the added for a NAND device
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (4 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <ezequiel@collabora.com>
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (2 preceding siblings ...)
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
` (3 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (3 preceding siblings ...)
2021-08-01 23:45 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
` (2 subsequent siblings)
7 siblings, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <joern@wh.fh-wedel.de>
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 <ezequiel@collabora.com>
---
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/3] mtdblock: Add comment about UBI block devices
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (4 preceding siblings ...)
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
2021-10-26 15:03 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Trevor Woerner
7 siblings, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <ezequiel@collabora.com>
---
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/3] mtdblock: Warn if the added for a NAND device
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (5 preceding siblings ...)
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
@ 2021-08-01 23:45 ` Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-10-26 15:03 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Trevor Woerner
7 siblings, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-01 23:45 UTC (permalink / raw)
To: linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra, Ezequiel Garcia
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 <ezequiel@collabora.com>
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
@ 2021-08-06 20:05 ` Miquel Raynal
2021-08-17 16:27 ` Ezequiel Garcia
0 siblings, 1 reply; 22+ messages in thread
From: Miquel Raynal @ 2021-08-06 20:05 UTC (permalink / raw)
To: Ezequiel Garcia, linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra
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 <ezequiel@collabora.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
Miquel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] mtdblock: Add comment about UBI block devices
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
@ 2021-08-06 20:05 ` Miquel Raynal
0 siblings, 0 replies; 22+ messages in thread
From: Miquel Raynal @ 2021-08-06 20:05 UTC (permalink / raw)
To: Ezequiel Garcia, linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra
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 <ezequiel@collabora.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
Miquel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
@ 2021-08-06 20:05 ` Miquel Raynal
0 siblings, 0 replies; 22+ messages in thread
From: Miquel Raynal @ 2021-08-06 20:05 UTC (permalink / raw)
To: Ezequiel Garcia, linux-mtd, linux-kernel, Richard Weinberger
Cc: Miquel Raynal, Vignesh Raghavendra
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 <joern@wh.fh-wedel.de>
> 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 <ezequiel@collabora.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
Miquel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device
2021-08-06 20:05 ` Miquel Raynal
@ 2021-08-17 16:27 ` Ezequiel Garcia
2021-08-17 16:49 ` Miquel Raynal
0 siblings, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2021-08-17 16:27 UTC (permalink / raw)
To: Miquel Raynal
Cc: Ezequiel Garcia, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Vignesh Raghavendra
Bonjour Miquel,
On Fri, 6 Aug 2021 at 17:05, Miquel Raynal <miquel.raynal@bootlin.com> 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 <ezequiel@collabora.com>
>
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] mtdblock: Warn if the added for a NAND device
2021-08-17 16:27 ` Ezequiel Garcia
@ 2021-08-17 16:49 ` Miquel Raynal
0 siblings, 0 replies; 22+ messages in thread
From: Miquel Raynal @ 2021-08-17 16:49 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Ezequiel Garcia, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Vignesh Raghavendra
Hi Ezequiel,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote on Tue, 17 Aug
2021 13:27:54 -0300:
> Bonjour Miquel,
>
> On Fri, 6 Aug 2021 at 17:05, Miquel Raynal <miquel.raynal@bootlin.com> 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 <ezequiel@collabora.com>
> >
> > 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
` (6 preceding siblings ...)
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
@ 2021-10-26 15:03 ` Trevor Woerner
2021-10-26 19:01 ` Richard Weinberger
2021-11-12 13:54 ` Ezequiel Garcia
7 siblings, 2 replies; 22+ messages in thread
From: Trevor Woerner @ 2021-10-26 15:03 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: linux-mtd, linux-kernel, Richard Weinberger, Miquel Raynal,
Vignesh Raghavendra
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-10-26 15:03 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Trevor Woerner
@ 2021-10-26 19:01 ` Richard Weinberger
2021-10-28 13:31 ` Trevor Woerner
2021-11-12 13:54 ` Ezequiel Garcia
1 sibling, 1 reply; 22+ messages in thread
From: Richard Weinberger @ 2021-10-26 19:01 UTC (permalink / raw)
To: Trevor Woerner
Cc: Ezequiel Garcia, linux-mtd, linux-kernel, Miquel Raynal,
Vignesh Raghavendra
Trevor,
----- Ursprüngliche Mail -----
> Von: "Trevor Woerner" <twoerner@gmail.com>
> An: "Ezequiel Garcia" <ezequiel@collabora.com>
> CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "richard"
> <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-10-26 19:01 ` Richard Weinberger
@ 2021-10-28 13:31 ` Trevor Woerner
2021-11-09 10:55 ` Miquel Raynal
2021-11-09 11:45 ` Daniel Golle
0 siblings, 2 replies; 22+ messages in thread
From: Trevor Woerner @ 2021-10-28 13:31 UTC (permalink / raw)
To: Richard Weinberger
Cc: Ezequiel Garcia, linux-mtd, linux-kernel, Miquel Raynal,
Vignesh Raghavendra
On Tue 2021-10-26 @ 09:01:32 PM, Richard Weinberger wrote:
> Trevor,
>
> ----- Ursprüngliche Mail -----
> > Von: "Trevor Woerner" <twoerner@gmail.com>
> > An: "Ezequiel Garcia" <ezequiel@collabora.com>
> > CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "richard"
> > <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>
> > 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-10-28 13:31 ` Trevor Woerner
@ 2021-11-09 10:55 ` Miquel Raynal
2021-11-09 11:45 ` Daniel Golle
1 sibling, 0 replies; 22+ messages in thread
From: Miquel Raynal @ 2021-11-09 10:55 UTC (permalink / raw)
To: Trevor Woerner
Cc: Richard Weinberger, Ezequiel Garcia, linux-mtd, linux-kernel,
Vignesh Raghavendra
Hi Trevor, Ezequiel,
twoerner@gmail.com 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" <twoerner@gmail.com>
> > > An: "Ezequiel Garcia" <ezequiel@collabora.com>
> > > CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "richard"
> > > <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>
> > > 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-10-28 13:31 ` Trevor Woerner
2021-11-09 10:55 ` Miquel Raynal
@ 2021-11-09 11:45 ` Daniel Golle
1 sibling, 0 replies; 22+ messages in thread
From: Daniel Golle @ 2021-11-09 11:45 UTC (permalink / raw)
To: Trevor Woerner
Cc: Richard Weinberger, Ezequiel Garcia, linux-mtd, linux-kernel,
Miquel Raynal, Vignesh Raghavendra
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" <twoerner@gmail.com>
> > > An: "Ezequiel Garcia" <ezequiel@collabora.com>
> > > CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "richard"
> > > <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>
> > > 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-10-26 15:03 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Trevor Woerner
2021-10-26 19:01 ` Richard Weinberger
@ 2021-11-12 13:54 ` Ezequiel Garcia
2022-01-20 9:39 ` Miquel Raynal
1 sibling, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2021-11-12 13:54 UTC (permalink / raw)
To: Trevor Woerner
Cc: Ezequiel Garcia, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Miquel Raynal, Vignesh Raghavendra
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 <twoerner@gmail.com> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2021-11-12 13:54 ` Ezequiel Garcia
@ 2022-01-20 9:39 ` Miquel Raynal
2022-01-20 10:26 ` Ezequiel Garcia
0 siblings, 1 reply; 22+ messages in thread
From: Miquel Raynal @ 2022-01-20 9:39 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Trevor Woerner, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Vignesh Raghavendra
Hi Ezequiel,
ezequiel@vanguardiasur.com.ar 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 <twoerner@gmail.com> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2022-01-20 9:39 ` Miquel Raynal
@ 2022-01-20 10:26 ` Ezequiel Garcia
2022-01-20 11:22 ` Miquel Raynal
0 siblings, 1 reply; 22+ messages in thread
From: Ezequiel Garcia @ 2022-01-20 10:26 UTC (permalink / raw)
To: Miquel Raynal
Cc: Trevor Woerner, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Vignesh Raghavendra
On Thu, 20 Jan 2022 at 06:39, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Ezequiel,
>
> ezequiel@vanguardiasur.com.ar 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 <twoerner@gmail.com> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] mtdblock: Advertise about UBI and UBI block
2022-01-20 10:26 ` Ezequiel Garcia
@ 2022-01-20 11:22 ` Miquel Raynal
0 siblings, 0 replies; 22+ messages in thread
From: Miquel Raynal @ 2022-01-20 11:22 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Trevor Woerner, linux-mtd, Linux Kernel Mailing List,
Richard Weinberger, Vignesh Raghavendra
Hi Ezequiel,
ezequiel@vanguardiasur.com.ar wrote on Thu, 20 Jan 2022 07:26:09 -0300:
> On Thu, 20 Jan 2022 at 06:39, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Ezequiel,
> >
> > ezequiel@vanguardiasur.com.ar 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 <twoerner@gmail.com> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2022-01-20 11:23 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01 23:45 [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Ezequiel Garcia
2021-08-01 23:45 ` [PATCH 1/3] mtdblock: Update old JFFS2 mention in Kconfig Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-08-01 23:45 ` [PATCH 2/3] mtdblock: Add comment about UBI block devices Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-08-01 23:45 ` [PATCH 3/3] mtdblock: Warn if the added for a NAND device Ezequiel Garcia
2021-08-06 20:05 ` Miquel Raynal
2021-08-17 16:27 ` Ezequiel Garcia
2021-08-17 16:49 ` Miquel Raynal
2021-10-26 15:03 ` [PATCH 0/3] mtdblock: Advertise about UBI and UBI block Trevor Woerner
2021-10-26 19:01 ` Richard Weinberger
2021-10-28 13:31 ` Trevor Woerner
2021-11-09 10:55 ` Miquel Raynal
2021-11-09 11:45 ` Daniel Golle
2021-11-12 13:54 ` Ezequiel Garcia
2022-01-20 9:39 ` Miquel Raynal
2022-01-20 10:26 ` Ezequiel Garcia
2022-01-20 11:22 ` Miquel Raynal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).