[OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash

[Maxime Ripard]

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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150125/365cf80f/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel