[U-Boot] [PATCH v2 9/14] sunxi: Enable UBI and NAND support

[Maxime Ripard <maxime.ripard@free-electrons.com>]

Hi Tom,

On Tue, Nov 22, 2016 at 10:24:27AM -0500, Tom Rini wrote:
> On Tue, Nov 22, 2016 at 01:38:39PM +0100, Maxime Ripard wrote:
> > From: Hans de Goede <hdegoede@redhat.com>
> > 
> > Enable the NAND and UBI support in the configuration header so that we can
> > (finally) use it.
> > 
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >  board/sunxi/Kconfig            |  8 ++++++++
> >  include/configs/sunxi-common.h | 14 ++++++++++++++
> >  2 files changed, 22 insertions(+), 0 deletions(-)
> > 
> > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> > index e1d4ab148f08..c6a620a20167 100644
> > --- a/board/sunxi/Kconfig
> > +++ b/board/sunxi/Kconfig
> > @@ -460,6 +460,14 @@ config AXP_GPIO
> >  	---help---
> >  	Say Y here to enable support for the gpio pins of the axp PMIC ICs.
> >  
> > +if NAND_SUNXI
> > +config CMD_NAND
> > +	default y
> > +
> > +config CMD_UBI
> > +	default y
> > +endif
> 
> We want to move away from adding 'default y' to board/*/Kconfig and
> instead have 'default y if ...' where the option is declared.

Yeah, I wasn't really sure about this. You can find the two
constructs in there. But ok, that's noted :)

> In this particular case we have a TODO of adding a NAND option that
> would be used to hide things like CMD_NAND and other sub-sections
> rather than using CMD_NAND for everything.

Ok.

> That said, we've just got 2 sunxi boards with NAND today right?  Maybe
> we shouldn't make this default for all sunxi boards yet, yes?  Thanks!

Not really. The huge majority of the rather old boards (basically
everything older than a year or so) is using NAND. However, they're
all using MLC NANDs, which are not supported into UBI right now.

The CHIP Pro is the only board with an Allwinner SoC and an SLC NAND,
hence why we can enable the NAND support.

However, in both cases (MLC and SLC), we'll need UBI. In the former
because other filesystems will not be reliable, in the latter because
the NAND is quite huge and the other filesystems would take an insane
amount of time to be accessed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161122/3963a16c/attachment.sig>