| Message ID | 1421164606-3222-4-git-send-email-maxime.ripard@free-electrons.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On 13 January 2015 at 16:56, Maxime Ripard <maxime.ripard@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).
Maxime, On Tue, 13 Jan 2015 16:56:40 +0100, Maxime Ripard <maxime.ripard@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
On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: > On 13 January 2015 at 16:56, Maxime Ripard > <maxime.ripard@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
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.ripard@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
On Thu, 22 Jan 2015 11:33:14 +0100, Maxime Ripard <maxime.ripard@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.ripard@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. >> 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. Thanks, Imre
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.ripard@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.ripard@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
Hi, On Sun, 25 Jan 2015 18:06:03 +0100, Maxime Ripard <maxime.ripard@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
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.ripard@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
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 <daniel@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 <daniel@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 <daniel@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 <daniel@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 <daniel@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 <daniel@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 <daniel@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 <daniel@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 <daniel@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) } }
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.ripard@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(-)