Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On Sun, Jan 25, 2015 at 08:50:32PM +0100, Imre Kaloz wrote: Hi, On Sun, 25 Jan 2015 18:06:03 +0100, Maxime Ripard maxime.rip...@free-electrons.com wrote: Sure, but please implement UBI on NOR as a generic solution. What do you mean? It already works quite well (with that patch applied and the NOR sub-profile), so I'm not sure I have to implement anything, be it generic or not. I've meant to make it generic, like the squashfs/ubfs/etc images so other targets can use it, too. Well, it uses only prepare_squashfs_image and UbinizeImage works great for that already, the only thing that differ is the set of options given to ubinize, so I'm not really sure how that can be turned into something more generic. The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you satisfied with the NAND support? Just to know if I can continue to model the NOR stuff on that. As I've written in the other mail, I'm mostly happy with it, but please make sure you don't hardcode available profiles but parse them. If we don't plan on supporting building single sub-profiles like ar71xx, I'm not even sure that we need to parse anything, we can just loop over the sub-profiles list in any case. I think supporting that could be handy so users (and people at Marvell) can just build what they want. Ok. But what/how do you want me to parse these profiles then? Apart from plumbing into the Profile macro itself to add the list of available profiles, and that would be way too intrusive, I don't really get what you expect here. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Hi, On Fri, Jan 23, 2015 at 01:57:44PM +0100, Imre Kaloz wrote: On Thu, 22 Jan 2015 11:33:14 +0100, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Wed, Jan 14, 2015 at 01:37:37PM +0100, Maxime Ripard wrote: On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: On 13 January 2015 at 16:56, Maxime Ripard maxime.rip...@free-electrons.com wrote: Some devices out there only have a NOR flash to store the rootfs on. While using UBI is arguable on this kind of NAND, this is something that should be supported. So why use UBI at all? Doesn't it make more sense to stick to the JFFS2? You should be even able to easily create 2 different image types (one for NOR, one for NAND) in one target (see bcm53xx). The Openblocks AX3 has a fairly large NOR (128MB) which would make JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. Is that case good enough for you? Sure, but please implement UBI on NOR as a generic solution. What do you mean? It already works quite well (with that patch applied and the NOR sub-profile), so I'm not sure I have to implement anything, be it generic or not. The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you satisfied with the NAND support? Just to know if I can continue to model the NOR stuff on that. As I've written in the other mail, I'm mostly happy with it, but please make sure you don't hardcode available profiles but parse them. If we don't plan on supporting building single sub-profiles like ar71xx, I'm not even sure that we need to parse anything, we can just loop over the sub-profiles list in any case. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Hi, On Sun, 25 Jan 2015 18:06:03 +0100, Maxime Ripard maxime.rip...@free-electrons.com wrote: Sure, but please implement UBI on NOR as a generic solution. What do you mean? It already works quite well (with that patch applied and the NOR sub-profile), so I'm not sure I have to implement anything, be it generic or not. I've meant to make it generic, like the squashfs/ubfs/etc images so other targets can use it, too. The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you satisfied with the NAND support? Just to know if I can continue to model the NOR stuff on that. As I've written in the other mail, I'm mostly happy with it, but please make sure you don't hardcode available profiles but parse them. If we don't plan on supporting building single sub-profiles like ar71xx, I'm not even sure that we need to parse anything, we can just loop over the sub-profiles list in any case. I think supporting that could be handy so users (and people at Marvell) can just build what they want. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Hi, On Wed, Jan 14, 2015 at 01:37:37PM +0100, Maxime Ripard wrote: On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: On 13 January 2015 at 16:56, Maxime Ripard maxime.rip...@free-electrons.com wrote: Some devices out there only have a NOR flash to store the rootfs on. While using UBI is arguable on this kind of NAND, this is something that should be supported. So why use UBI at all? Doesn't it make more sense to stick to the JFFS2? You should be even able to easily create 2 different image types (one for NOR, one for NAND) in one target (see bcm53xx). The Openblocks AX3 has a fairly large NOR (128MB) which would make JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. Is that case good enough for you? The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you satisfied with the NAND support? Just to know if I can continue to model the NOR stuff on that. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Maxime, On Tue, 13 Jan 2015 16:56:40 +0100, Maxime Ripard maxime.rip...@free-electrons.com wrote: Some devices out there only have a NOR flash to store the rootfs on. While using UBI is arguable on this kind of NAND, this is something that should be supported. Could you explain me, why would we want that? For NOR we use squashfs+jffs2 everywhere. Thanks, Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On 13 January 2015 at 16:56, Maxime Ripard maxime.rip...@free-electrons.com wrote: Some devices out there only have a NOR flash to store the rootfs on. While using UBI is arguable on this kind of NAND, this is something that should be supported. So why use UBI at all? Doesn't it make more sense to stick to the JFFS2? You should be even able to easily create 2 different image types (one for NOR, one for NAND) in one target (see bcm53xx). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: On 13 January 2015 at 16:56, Maxime Ripard maxime.rip...@free-electrons.com wrote: Some devices out there only have a NOR flash to store the rootfs on. While using UBI is arguable on this kind of NAND, this is something that should be supported. So why use UBI at all? Doesn't it make more sense to stick to the JFFS2? You should be even able to easily create 2 different image types (one for NOR, one for NAND) in one target (see bcm53xx). The Openblocks AX3 has a fairly large NOR (128MB) which would make JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. That does make sense though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Some devices out there only have a NOR flash to store the rootfs on.
While using UBI is arguable on this kind of NAND, this is something that should
be supported.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 002a79ab73d1..27ed474127b3 100644
---
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1207,6 +1207,48 @@ static struct mtd_info * __init open_mtd
+@@ -1207,6 +1207,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd-type == MTD_NANDFLASH ||
++ mtd-type == MTD_NORFLASH ||
+ mtd-type == MTD_DATAFLASH ||
+ mtd-type == MTD_MLCNANDFLASH) {
+ mutex_lock(ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1290,6 +1332,12 @@ static int __init ubi_init(void)
+@@ -1290,6 +1333,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd-type == MTD_NANDFLASH ||
++ mtd-type == MTD_NORFLASH ||
+ mtd-type == MTD_DATAFLASH ||
+ mtd-type == MTD_MLCNANDFLASH) {
+ mutex_lock(ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd-type == MTD_NANDFLASH ||
++ mtd-type == MTD_NORFLASH ||
+ mtd-type == MTD_DATAFLASH ||
+ mtd-type == MTD_MLCNANDFLASH) {
+ mutex_lock(ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle dan...@makrotopia.org
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
