[linux-sunxi] Re: [U-Boot] cmd, nand: add an option to disable the verification when writing in raw mode

2016-07-25 Thread Boris Brezillon
On Sun, 24 Jul 2016 20:41:30 -0500
Scott Wood <o...@buserror.net> wrote:

> On Wed, Jun 15, 2016 at 10:42:18AM +0200, Boris Brezillon wrote:
> > diff --git a/cmd/nand.c b/cmd/nand.c
> > index 583a18f..3a5e3a0 100644
> > --- a/cmd/nand.c
> > +++ b/cmd/nand.c
> > @@ -306,7 +306,7 @@ static void nand_print_and_set_info(int idx)
> >  }
> >  
> >  static int raw_access(struct mtd_info *mtd, ulong addr, loff_t off,
> > - ulong count, int read)
> > + ulong count, int read, int noverify)
> >  {
> > int ret = 0;
> >  
> > @@ -324,7 +324,7 @@ static int raw_access(struct mtd_info *mtd, ulong addr, 
> > loff_t off,
> > ret = mtd_read_oob(mtd, off, );
> > } else {
> > ret = mtd_write_oob(mtd, off, );
> > -   if (!ret)
> > +   if (!ret && !no_verify)
> > ret = nand_verify_page_oob(mtd, , off);  
> 
> "noverify" versus "no_verify"...  I've fixed it while applying.

Oops, sorry about that.

> 
> I assume/hope that you just sent an old version by mistake, and that this
> was actually tested?

Yes, it was tested, just forgot to amend my commit :-(.
Thanks for fixing the problem.

Regards,

Boris


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v7 1/2] mtd: nand: sunxi: update DT bindings

2016-06-24 Thread Boris Brezillon
On Fri, 24 Jun 2016 13:00:04 +0800
Icenowy Zheng  wrote:

> Document the reset lines
> 
> Signed-off-by: Icenowy Zheng 

Applied both.

Thanks,

Boris

> ---
> Changes in v7:
>   - Rebased for nand/next branch.
>   - Merged the two part of "Optional properties" of nand/next's document
> into one part.
> 
>  Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
> b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> index 6fdf8f6..b040ed4 100644
> --- a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> @@ -14,17 +14,17 @@ Required properties:
>  Optional properties:
>  - dmas : shall reference DMA channel associated to the NAND controller.
>  - dma-names : shall be "rxtx".
> -
> -Optional children nodes:
> -Children nodes represent the available nand chips.
> -
> -Optional properties:
> +- reset : phandle + reset specifier pair
> +- reset-names : shall be "ahb" if present
>  - allwinner,rb : shall contain the native Ready/Busy ids.
>   or
>  - rb-gpios : shall contain the gpios used as R/B pins.
>  - nand-ecc-mode : one of the supported ECC modes ("hw", "hw_syndrome", 
> "soft",
>"soft_bch" or "none")
>  
> +Optional children nodes:
> +Children nodes represent the available nand chips.
> +
>  see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v6 2/2] mtd: nand: sunxi: add reset line support

2016-06-23 Thread Boris Brezillon
On Fri, 24 Jun 2016 07:20:38 +0800
Icenowy Zheng <icen...@aosc.xyz> wrote:

> In my opinion, return directly PTR_ERR(nfc->reset) is OK here.
> If devm_reset_control_get_optional() return -EPROBE_DEFER, the code here will 
> also return it. However, if we get other error, why should it return 
> -EPROBE_DEFER again?

Sorry, I just had a brainfart :-). Your implementation is correct.
BTW, can you avoid top-posting and reply inline?

> 
> 24.06.2016, 00:01, "Boris Brezillon" <boris.brezil...@free-electrons.com>:
> > On Mon, 20 Jun 2016 12:48:38 +0800
> > Icenowy Zheng <icen...@aosc.xyz> wrote:
> >  
> >>  The NAND controller on some sun8i chips needs its reset line to be
> >>  deasserted before they can enter working state.
> >>
> >>  Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> >>  ---
> >>    Changes in v2:
> >>  - Corrected the error checking code of reset line.
> >>
> >>    Changes in v3:
> >>  - Corrected a more serious error brought in the "fix" of v2.
> >>
> >>    Changes in v4:
> >>  - Removed unneeded code block after "else".
> >>
> >>    Changes in v5:
> >>  - Added reassertion code in case of initialization error and device
> >>    remove.
> >>
> >>    Changes in v6:
> >>  - Fixed a resource leak by not using goto to exit in case of error.
> >>
> >>   drivers/mtd/nand/sunxi_nand.c | 28 +---
> >>   1 file changed, 25 insertions(+), 3 deletions(-)
> >>
> >>  diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> >>  index a83a690..08d5e88 100644
> >>  --- a/drivers/mtd/nand/sunxi_nand.c
> >>  +++ b/drivers/mtd/nand/sunxi_nand.c
> >>  @@ -39,6 +39,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >>  +#include 
> >>
> >>   #define NFC_REG_CTL 0x
> >>   #define NFC_REG_ST 0x0004
> >>  @@ -269,6 +270,7 @@ struct sunxi_nfc {
> >>   void __iomem *regs;
> >>   struct clk *ahb_clk;
> >>   struct clk *mod_clk;
> >>  + struct reset_control *reset;
> >>   unsigned long assigned_cs;
> >>   unsigned long clk_rate;
> >>   struct list_head chips;
> >>  @@ -1871,26 +1873,42 @@ static int sunxi_nfc_probe(struct platform_device 
> >> *pdev)
> >>   if (ret)
> >>   goto out_ahb_clk_unprepare;
> >>
> >>  + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> >>  +
> >>  + if (!IS_ERR(nfc->reset)) {
> >>  + ret = reset_control_deassert(nfc->reset);
> >>  + if (ret) {
> >>  + dev_err(dev, "reset err %d\n", ret);
> >>  + goto out_mod_clk_unprepare;
> >>  + }
> >>  + } else if (PTR_ERR(nfc->reset) != -ENOENT) {
> >>  + ret = PTR_ERR(nfc->reset);  
> >
> > You should return -EDEFER_PROBE here.
> >
> > And can you please rebase this series on top of nand/next [1]?
> >
> > [1]https://github.com/linux-nand/linux/tree/nand/next  

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v6 2/2] mtd: nand: sunxi: add reset line support

2016-06-23 Thread Boris Brezillon
On Mon, 20 Jun 2016 12:48:38 +0800
Icenowy Zheng  wrote:

> The NAND controller on some sun8i chips needs its reset line to be
> deasserted before they can enter working state.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>   Changes in v2:
>     - Corrected the error checking code of reset line.
> 
>   Changes in v3:
>     - Corrected a more serious error brought in the "fix" of v2.
> 
>   Changes in v4:
>     - Removed unneeded code block after "else".
> 
>   Changes in v5:
>     - Added reassertion code in case of initialization error and device
>   remove.
> 
>   Changes in v6:
> - Fixed a resource leak by not using goto to exit in case of error.
> 
>  drivers/mtd/nand/sunxi_nand.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index a83a690..08d5e88 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define NFC_REG_CTL  0x
>  #define NFC_REG_ST   0x0004
> @@ -269,6 +270,7 @@ struct sunxi_nfc {
>   void __iomem *regs;
>   struct clk *ahb_clk;
>   struct clk *mod_clk;
> + struct reset_control *reset;
>   unsigned long assigned_cs;
>   unsigned long clk_rate;
>   struct list_head chips;
> @@ -1871,26 +1873,42 @@ static int sunxi_nfc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto out_ahb_clk_unprepare;
>  
> + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> +
> + if (!IS_ERR(nfc->reset)) {
> + ret = reset_control_deassert(nfc->reset);
> + if (ret) {
> + dev_err(dev, "reset err %d\n", ret);
> + goto out_mod_clk_unprepare;
> + }
> + } else if (PTR_ERR(nfc->reset) != -ENOENT) {
> + ret = PTR_ERR(nfc->reset);

You should return -EDEFER_PROBE here.

And can you please rebase this series on top of nand/next [1]?

[1]https://github.com/linux-nand/linux/tree/nand/next

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 2/2] mtd: nand: sunxi: add reset line support

2016-06-20 Thread Boris Brezillon
Hi Philipp,

On Mon, 20 Jun 2016 14:05:54 +0200
Philipp Zabel <p.za...@pengutronix.de> wrote:

> Am Sonntag, den 19.06.2016, 14:06 +0200 schrieb Boris Brezillon:
> > +Philipp
> > 
> > On Sun, 19 Jun 2016 19:37:39 +0800
> > Icenowy Zheng <icen...@aosc.xyz> wrote:
> >   
> > > The NAND controller on some sun8i chips needs its reset line to be 
> > > deasserted
> > > before they can enter working state. This commit added the reset line 
> > > process
> > > to the driver.
> > > 
> > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> > > ---
> > >  drivers/mtd/nand/sunxi_nand.c | 14 ++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> > > index a83a690..1502748 100644
> > > --- a/drivers/mtd/nand/sunxi_nand.c
> > > +++ b/drivers/mtd/nand/sunxi_nand.c
> > > @@ -39,6 +39,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #define NFC_REG_CTL  0x
> > >  #define NFC_REG_ST   0x0004
> > > @@ -269,6 +270,7 @@ struct sunxi_nfc {
> > >   void __iomem *regs;
> > >   struct clk *ahb_clk;
> > >   struct clk *mod_clk;
> > > + struct reset_control *reset;
> > >   unsigned long assigned_cs;
> > >   unsigned long clk_rate;
> > >   struct list_head chips;
> > > @@ -1871,6 +1873,18 @@ static int sunxi_nfc_probe(struct platform_device 
> > > *pdev)
> > >   if (ret)
> > >   goto out_ahb_clk_unprepare;
> > >  
> > > + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> > > + if (PTR_ERR(nfc->reset) == -EPROBE_DEFER)
> > > + return PTR_ERR(nfc->reset);  
> > 
> > Actually you should test for != -ENOENT, because all error codes except
> > this one should stop the ->probe().
> > 
> > BTW, this devm_reset_control_get_optional() is really weird. While most
> > _optional() methods return NULL when the element is not defined in the
> > DT, this one returns -ENOTENT, which makes it impossible to
> > differentiate a real error from a undefined reset line (which is a
> > valid case for _optional()).  
> 
> Of course it's possible, -ENOENT is only returned if the reset line is
> not defined in the device tree.

Okay, testing for err != -ENOENT is the right thing to do here. Maybe
this could be documented.

> 
> Note that gpiod_get_(index_)optional do nothing more that replacing
> -ENOENT with NULL. And phydev_optional_get replaces -ENODEV with NULL.
> And regulator_get_optional, if I understand it correctly, never returns
> NULL.
> 
> > Philipp, is there a good reason for doing that?  
> 
> Historically, NULL has not been a valid value for rstc. I suppose we
> could add NULL checks to the reset_control_assert/deassert/reset/status
> functions and align the reset API a bit with gpiod. I just wouldn't want
> to see any IS_ERR_OR_NULL error handling in the drivers.

Well, returning NULL is mainly a convenient way to differentiate real
errors from missing optional reset lines (which are not errors). Now,
if you say checking for -ENOENT is the right thing to do here, I'm
fine with that.

Regards,

Boris

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 0/3] mtd: nand: sunxi: fix SLC NAND support

2016-06-20 Thread Boris Brezillon
On Mon,  6 Jun 2016 13:59:11 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> Hello,
> 
> Those 3 patches aims a fixing support for SLC NANDs with rather small
> NAND pages (<= 4k).
> 
> The first patch promote 512 bytes ECC steps to 1k steps, which should
> both save a few OOB bytes and provide stronger ECC.
> The second patch checks the ECC step value, and rejects any NAND that
> requires ECC steps != 512 | 1024.
> The last patch implements ecc->write_subpage(), thus fixing a NULL
> pointer dereference when the NAND chip supports subpage write.

Applied.

> 
> Best Regards,
> 
> Boris
> 
> Boris Brezillon (3):
>   mtd: nand: sunxi: prefer 1k ECC blocks when applicable
>   mtd: nand: sunxi: check ecc->size values
>   mtd: nand: sunxi: fix subpage write
> 
>  drivers/mtd/nand/sunxi_nand.c | 42 +-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH] mtd: nand: sunxi: Fix OOB bytes retrieval in read_chunks_dma()

2016-06-20 Thread Boris Brezillon
On Wed, 15 Jun 2016 11:22:12 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> The column address passed to the RNDOUT operation was missing the page
> size offset.
> 

Applied.

> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> Fixes: 614049a8d904 ("mtd: nand: sunxi: add support for DMA assisted 
> operations")
> ---
>  drivers/mtd/nand/sunxi_nand.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index ea74827..bcdd015 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -1094,7 +1094,8 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct 
> mtd_info *mtd, uint8_t *buf,
>  
>   if (oob_required && !erased) {
>   /* TODO: use DMA to retrieve OOB */
> - nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
> + nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
> +   mtd->writesize + oob_off, -1);
>   nand->read_buf(mtd, oob, ecc->bytes + 4);
>  
>   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, i,
> @@ -1129,7 +1130,8 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct 
> mtd_info *mtd, uint8_t *buf,
>   }
>  
>   /* TODO: use DMA to retrieve OOB */
> - nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
> + nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
> +   mtd->writesize + oob_off, -1);
>   nand->read_buf(mtd, oob, ecc->bytes + 4);
>  
>   ret = nand_check_erased_ecc_chunk(data, ecc->size,

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot,v3,3/7] spl: nand: support redundant u-boot image

2016-06-20 Thread Boris Brezillon
On Sun, 19 Jun 2016 19:07:47 -0500
Scott Wood <o...@buserror.net> wrote:

> On Mon, Jun 06, 2016 at 10:16:58AM +0200, Boris Brezillon wrote:
> > On modern NAND it's more than recommended to have a backup copy of the
> > u-boot binary to recover from corruption: bitflips are quite common on
> > MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
> > more quickly than what you would see on an SLC NAND.
> > 
> > Add an extra Kconfig option to specify the offset of the redundant u-boot
> > image.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > Acked-by: Hans de Goede <hdego...@redhat.com>
> > 
> > # Conflicts:
> > #   common/spl/spl_nand.c
> > #   drivers/mtd/nand/Kconfig
> > ---
> >  common/spl/spl_nand.c| 5 +
> >  drivers/mtd/nand/Kconfig | 8 
> >  2 files changed, 13 insertions(+)
> > 
> > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> > index bbd9546..d8c5b9e 100644
> > --- a/common/spl/spl_nand.c
> > +++ b/common/spl/spl_nand.c
> > @@ -107,6 +107,11 @@ int spl_nand_load_image(void)
> >  #endif
> > /* Load u-boot */
> > err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
> > +#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
> > +   if (err)
> > +   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
> > +   header);
> > +#endif
> > nand_deselect();
> > return err;
> >  }
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index 5fe169f..8c46a2f 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -117,6 +117,14 @@ config SYS_NAND_U_BOOT_OFFS
> > Set the offset from the start of the nand where u-boot should be
> > loaded from.
> >  
> > +config SYS_NAND_U_BOOT_OFFS_REDUND
> > +   hex "Location in NAND to read U-Boot from"
> > +   default SYS_NAND_U_BOOT_OFFS
> > +   depends on SYS_NAND_U_BOOT_LOCATIONS
> > +   help
> > +   Set the offset from the start of the nand where the redundant u-boot
> > +   should be loaded from.
> > +
> >  config SPL_NAND_DENALI
> > bool "Support Denali NAND controller for SPL"
> > help  
> 
> I'm adding the below ifdef while applying, so that the build doesn't
> break on targets that don't define CONFIG_SYS_NAND_U_BOOT_LOCATIONS.

Oops. I previously had

#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
#endif

at the beginning of the file, but I removed it when switching to the
approach you suggested.

Thanks for fixing that.

Regards,

Boris

> 
> diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> index 952f644..0e35e0f 100644
> --- a/common/spl/spl_nand.c
> +++ b/common/spl/spl_nand.c
> @@ -134,11 +134,13 @@ int spl_nand_load_image(void)
>  #endif
>   /* Load u-boot */
>   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
> +#ifdef CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
>  #if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
>   if (err)
>   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
>   header);
>  #endif
> +#endif
>   nand_deselect();
>   return err;
>  }
> 
> 
> -Scott

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v4 2/2] mtd: nand: sunxi: add reset line support

2016-06-19 Thread Boris Brezillon
On Sun, 19 Jun 2016 23:40:35 +0800
Icenowy Zheng  wrote:

> The NAND controller on some sun8i chips needs its reset line to be deasserted
> before they can enter working state. This commit added the reset line process
> to the driver.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
>   - Corrected the error checking code of reset line.
> 
> Changes in v3:
>   - Corrected a more serious error brought in the "fix" of v2.
> 
> Changes in v4:
>   - Removed unneeded code block after "else".
> 
>  drivers/mtd/nand/sunxi_nand.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index a83a690..b37075b 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define NFC_REG_CTL  0x
>  #define NFC_REG_ST   0x0004
> @@ -269,6 +270,7 @@ struct sunxi_nfc {
>   void __iomem *regs;
>   struct clk *ahb_clk;
>   struct clk *mod_clk;
> + struct reset_control *reset;
>   unsigned long assigned_cs;
>   unsigned long clk_rate;
>   struct list_head chips;
> @@ -1871,6 +1873,19 @@ static int sunxi_nfc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto out_ahb_clk_unprepare;
>  
> + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> +
> + if (!IS_ERR(nfc->reset)) {
> + ret = reset_control_deassert(nfc->reset);
> + if (ret) {
> + dev_err(dev, "reset err %d\n", ret);
> + goto out_mod_clk_unprepare;
> + }
> + }
> + else if (PTR_ERR(nfc->reset) != -ENOENT) {

} else if (...) {

> + return PTR_ERR(nfc->reset);
> + }
> +
>   ret = sunxi_nfc_rst(nfc);
>   if (ret)
>   goto out_mod_clk_unprepare;


And you should probably reassert the reset line in case of errors and
in the ->remove() hook.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v3 2/2] mtd: nand: sunxi: add reset line support

2016-06-19 Thread Boris Brezillon
On Sun, 19 Jun 2016 23:01:28 +0800
Icenowy Zheng  wrote:

> The NAND controller on some sun8i chips needs its reset line to be deasserted
> before they can enter working state. This commit added the reset line process
> to the driver.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v1:
>   - Corrected the error checking code of reset line.
> 
> Changes in v2:
>   - Corrected a more serious error brought in the "fix" of v1.
> 
>  drivers/mtd/nand/sunxi_nand.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index a83a690..8fb5899 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define NFC_REG_CTL  0x
>  #define NFC_REG_ST   0x0004
> @@ -269,6 +270,7 @@ struct sunxi_nfc {
>   void __iomem *regs;
>   struct clk *ahb_clk;
>   struct clk *mod_clk;
> + struct reset_control *reset;
>   unsigned long assigned_cs;
>   unsigned long clk_rate;
>   struct list_head chips;
> @@ -1871,6 +1873,20 @@ static int sunxi_nfc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto out_ahb_clk_unprepare;
>  
> + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> +
> + if (!IS_ERR(nfc->reset)) {
> + ret = reset_control_deassert(nfc->reset);
> + if (ret) {
> + dev_err(dev, "reset err %d\n", ret);
> + goto out_mod_clk_unprepare;
> + }
> + }
> + else {
> + if (PTR_ERR(nfc->reset) != -ENOENT)

} else if (PTR_ERR(nfc->reset) != -ENOENT) {

> + return PTR_ERR(nfc->reset);
> + }
> +
>   ret = sunxi_nfc_rst(nfc);
>   if (ret)
>   goto out_mod_clk_unprepare;

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 2/2] mtd: nand: sunxi: add reset line support

2016-06-19 Thread Boris Brezillon
On Sun, 19 Jun 2016 21:11:00 +0800
icen...@aosc.xyz wrote:

> Then I will soon make the v2 patch set, with the error detection part fixed.
> 
> But why does sunxi-mmc check only EPROBE_DEFER?

I guess someone had a probe-dependency problem and fixed this case but
ignored all the possible errors. But there may be other reasons for
devm_reset_control_get_optional() to fail. The only one that is really
reflecting that the reset line is not defined in the DT is -ENOENT.

> 
> 19.06.2016, 20:53, "Boris Brezillon" <boris.brezil...@free-electrons.com>:
> > On Sun, 19 Jun 2016 20:41:09 +0800
> > icen...@aosc.xyz wrote:
> >  
> >>  To be honest, I copied them from sunxi-mmc.c.
> >>
> >>  What function should be chosen better?  
> >
> > You did the right thing (except for the error detection part). My
> > question was addressed to Philipp (the reset subsystem maintainer).
> >  
> >>  19.06.2016, 20:06, "Boris Brezillon" 
> >> <boris.brezil...@free-electrons.com>:  
> >>  > +Philipp
> >>  >
> >>  > On Sun, 19 Jun 2016 19:37:39 +0800
> >>  > Icenowy Zheng <icen...@aosc.xyz> wrote:
> >>  >  
> >>  >>  The NAND controller on some sun8i chips needs its reset line to be 
> >> deasserted
> >>  >>  before they can enter working state. This commit added the reset line 
> >> process
> >>  >>  to the driver.
> >>  >>
> >>  >>  Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> >>  >>  ---
> >>  >>   drivers/mtd/nand/sunxi_nand.c | 14 ++
> >>  >>   1 file changed, 14 insertions(+)
> >>  >>
> >>  >>  diff --git a/drivers/mtd/nand/sunxi_nand.c 
> >> b/drivers/mtd/nand/sunxi_nand.c
> >>  >>  index a83a690..1502748 100644
> >>  >>  --- a/drivers/mtd/nand/sunxi_nand.c
> >>  >>  +++ b/drivers/mtd/nand/sunxi_nand.c
> >>  >>  @@ -39,6 +39,7 @@
> >>  >>   #include 
> >>  >>   #include 
> >>  >>   #include 
> >>  >>  +#include 
> >>  >>
> >>  >>   #define NFC_REG_CTL 0x
> >>  >>   #define NFC_REG_ST 0x0004
> >>  >>  @@ -269,6 +270,7 @@ struct sunxi_nfc {
> >>  >>   void __iomem *regs;
> >>  >>   struct clk *ahb_clk;
> >>  >>   struct clk *mod_clk;
> >>  >>  + struct reset_control *reset;
> >>  >>   unsigned long assigned_cs;
> >>  >>   unsigned long clk_rate;
> >>  >>   struct list_head chips;
> >>  >>  @@ -1871,6 +1873,18 @@ static int sunxi_nfc_probe(struct 
> >> platform_device *pdev)
> >>  >>   if (ret)
> >>  >>   goto out_ahb_clk_unprepare;
> >>  >>
> >>  >>  + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> >>  >>  + if (PTR_ERR(nfc->reset) == -EPROBE_DEFER)
> >>  >>  + return PTR_ERR(nfc->reset);  
> >>  >
> >>  > Actually you should test for != -ENOENT, because all error codes except
> >>  > this one should stop the ->probe().
> >>  >
> >>  > BTW, this devm_reset_control_get_optional() is really weird. While most
> >>  > _optional() methods return NULL when the element is not defined in the
> >>  > DT, this one returns -ENOTENT, which makes it impossible to
> >>  > differentiate a real error from a undefined reset line (which is a
> >>  > valid case for _optional()).
> >>  >
> >>  > Philipp, is there a good reason for doing that?
> >>  >  
> >>  >>  +
> >>  >>  + if (!IS_ERR(nfc->reset)) {
> >>  >>  + ret = reset_control_deassert(nfc->reset);
> >>  >>  + if (ret) {
> >>  >>  + dev_err(dev, "reset err %d\n", ret);
> >>  >>  + goto out_mod_clk_unprepare;
> >>  >>  + }
> >>  >>  + }
> >>  >>  +  

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 2/2] mtd: nand: sunxi: add reset line support

2016-06-19 Thread Boris Brezillon
On Sun, 19 Jun 2016 20:41:09 +0800
icen...@aosc.xyz wrote:

> To be honest, I copied them from sunxi-mmc.c.
> 
> What function should be chosen better?

You did the right thing (except for the error detection part). My
question was addressed to Philipp (the reset subsystem maintainer).

> 
> 
> 19.06.2016, 20:06, "Boris Brezillon" <boris.brezil...@free-electrons.com>:
> > +Philipp
> >
> > On Sun, 19 Jun 2016 19:37:39 +0800
> > Icenowy Zheng <icen...@aosc.xyz> wrote:
> >  
> >>  The NAND controller on some sun8i chips needs its reset line to be 
> >> deasserted
> >>  before they can enter working state. This commit added the reset line 
> >> process
> >>  to the driver.
> >>
> >>  Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> >>  ---
> >>   drivers/mtd/nand/sunxi_nand.c | 14 ++
> >>   1 file changed, 14 insertions(+)
> >>
> >>  diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> >>  index a83a690..1502748 100644
> >>  --- a/drivers/mtd/nand/sunxi_nand.c
> >>  +++ b/drivers/mtd/nand/sunxi_nand.c
> >>  @@ -39,6 +39,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >>  +#include 
> >>
> >>   #define NFC_REG_CTL 0x
> >>   #define NFC_REG_ST 0x0004
> >>  @@ -269,6 +270,7 @@ struct sunxi_nfc {
> >>   void __iomem *regs;
> >>   struct clk *ahb_clk;
> >>   struct clk *mod_clk;
> >>  + struct reset_control *reset;
> >>   unsigned long assigned_cs;
> >>   unsigned long clk_rate;
> >>   struct list_head chips;
> >>  @@ -1871,6 +1873,18 @@ static int sunxi_nfc_probe(struct platform_device 
> >> *pdev)
> >>   if (ret)
> >>   goto out_ahb_clk_unprepare;
> >>
> >>  + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> >>  + if (PTR_ERR(nfc->reset) == -EPROBE_DEFER)
> >>  + return PTR_ERR(nfc->reset);  
> >
> > Actually you should test for != -ENOENT, because all error codes except
> > this one should stop the ->probe().
> >
> > BTW, this devm_reset_control_get_optional() is really weird. While most
> > _optional() methods return NULL when the element is not defined in the
> > DT, this one returns -ENOTENT, which makes it impossible to
> > differentiate a real error from a undefined reset line (which is a
> > valid case for _optional()).
> >
> > Philipp, is there a good reason for doing that?
> >  
> >>  +
> >>  + if (!IS_ERR(nfc->reset)) {
> >>  + ret = reset_control_deassert(nfc->reset);
> >>  + if (ret) {
> >>  + dev_err(dev, "reset err %d\n", ret);
> >>  + goto out_mod_clk_unprepare;
> >>  + }
> >>  + }
> >>  +  

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 2/2] mtd: nand: sunxi: add reset line support

2016-06-19 Thread Boris Brezillon
+Philipp

On Sun, 19 Jun 2016 19:37:39 +0800
Icenowy Zheng  wrote:

> The NAND controller on some sun8i chips needs its reset line to be deasserted
> before they can enter working state. This commit added the reset line process
> to the driver.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/mtd/nand/sunxi_nand.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index a83a690..1502748 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define NFC_REG_CTL  0x
>  #define NFC_REG_ST   0x0004
> @@ -269,6 +270,7 @@ struct sunxi_nfc {
>   void __iomem *regs;
>   struct clk *ahb_clk;
>   struct clk *mod_clk;
> + struct reset_control *reset;
>   unsigned long assigned_cs;
>   unsigned long clk_rate;
>   struct list_head chips;
> @@ -1871,6 +1873,18 @@ static int sunxi_nfc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto out_ahb_clk_unprepare;
>  
> + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> + if (PTR_ERR(nfc->reset) == -EPROBE_DEFER)
> + return PTR_ERR(nfc->reset);

Actually you should test for != -ENOENT, because all error codes except
this one should stop the ->probe().

BTW, this devm_reset_control_get_optional() is really weird. While most
_optional() methods return NULL when the element is not defined in the
DT, this one returns -ENOTENT, which makes it impossible to
differentiate a real error from a undefined reset line (which is a
valid case for _optional()).

Philipp, is there a good reason for doing that?

> +
> + if (!IS_ERR(nfc->reset)) {
> + ret = reset_control_deassert(nfc->reset);
> + if (ret) {
> + dev_err(dev, "reset err %d\n", ret);
> + goto out_mod_clk_unprepare;
> + }
> + }
> +

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v3 0/7] spl: nand: sunxi: implement auto-detection

2016-06-15 Thread Boris Brezillon
On Mon,  6 Jun 2016 10:16:55 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> Hello,
> 
> This patch series aims at adding support for NAND auto-detection to
> the sunxi SPL NAND driver.
> 
> As explained in patch 7, this auto-detection is nothing more than a
> dumb "trial and error" logic, but it allows one to use the same
> SPL binary for all kind of sunxi boards booting from NAND.
> Of course, this approach might increase a bit the boot-time, but this
> is something we could address by adding a "default NAND config",
> that would be tested before launching the auto-detection procedure.
> 
> Now let's detail a bit what's inside this patch-set.
> Patch 1 is a cleanup removing support for BootROM configs, which in
> my opinion are not only inefficient but also not reliable (at least
> the current implementation does not guarantee that you'll be using
> the correct configuration when reading the NAND).
> 
> Piotr, Hans, any comment?
> Is this a real problem if we get rid of syndrome/BootROM configs?
> I mean, are you really using this mode? If that's not the case, I'd
> prefer dropping support for this feature. ITOH, if you really
> need this mode, then I'd recommend adding Kconfig options to specify
> the exact config to be used rather than randomly testing configs
> (see my explanation in patch 1).
> 
> Patch 2 is reworking the SYS_NAND_U_BOOT_OFFS Kconfig dependency model
> to make it usable on all platforms (not only sunxi).
> 
> Patch 3 is adding generic support for redundant u-boot images, which
> is particularly useful on modern NANDs where corruptions is likely to
> happen.
> Patch 4 is just getting rid of the open-coded version of redundant
> u-boot image support in the sunxi NAND driver.
> 
> Patch 5 is a simple improvement of the NAND controller status polling
> loop, which is really important to make the "trial and error"
> approach efficient (we try to limit the impact on boot-time here).
> Patch 6 and 7 are implementing the auto-detection logic.

Scott, can you have a look at this version and let me know if this is
what you had in mind for the Kconfig options?

> 
> Best Regards,
> 
> Boris
> 
> Changes since v2:
> - rework the Kconfig options for SYS_U_BOOT_OFFS and
>   SYS_U_BOOT_REDUND_OFFS
> 
> Changes since v1:
> - added Hans ack
> - fixed 2 typos in patch 7
> 
> Boris Brezillon (7):
>   spl: nand: sunxi: remove support for so-called 'syndrome' mode
>   spl: nand: rework SYS_NAND_U_BOOT_OFFS Kconfig option dependency
>   spl: nand: support redundant u-boot image
>   spl: nand: sunxi: stop guessing the redundant u-boot offset
>   spl: nand: sunxi: rework status polling loop
>   spl: nand: sunxi: split 'load page' and 'read page' logic
>   spl: nand: sunxi: add support for NAND config auto-detection
> 
>  common/spl/spl_nand.c     |   5 +
>  drivers/mtd/nand/Kconfig  |  21 +-
>  drivers/mtd/nand/sunxi_nand_spl.c | 480 
> --
>  3 files changed, 332 insertions(+), 174 deletions(-)
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH] mtd: nand: sunxi: Fix OOB bytes retrieval in read_chunks_dma()

2016-06-15 Thread Boris Brezillon
The column address passed to the RNDOUT operation was missing the page
size offset.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Fixes: 614049a8d904 ("mtd: nand: sunxi: add support for DMA assisted 
operations")
---
 drivers/mtd/nand/sunxi_nand.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index ea74827..bcdd015 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1094,7 +1094,8 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct 
mtd_info *mtd, uint8_t *buf,
 
if (oob_required && !erased) {
/* TODO: use DMA to retrieve OOB */
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
+ mtd->writesize + oob_off, -1);
nand->read_buf(mtd, oob, ecc->bytes + 4);
 
sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, i,
@@ -1129,7 +1130,8 @@ static int sunxi_nfc_hw_ecc_read_chunks_dma(struct 
mtd_info *mtd, uint8_t *buf,
}
 
/* TODO: use DMA to retrieve OOB */
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
+ mtd->writesize + oob_off, -1);
nand->read_buf(mtd, oob, ecc->bytes + 4);
 
ret = nand_check_erased_ecc_chunk(data, ecc->size,
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH] cmd, nand: add an option to disable the verification when writing in raw mode

2016-06-15 Thread Boris Brezillon
Modern NANDs do not guarantee that data written in raw mode will not
contain bitflips just after writing them. This is fine since the number
of bitflips should be rather low and thus fixable by the ECC engine,
but since we are reading data in raw mode to verify if they match the
input data we cannot prevent failures if some bits are flipped.

The option of using standard mode to verify the data is not acceptable
either, since one of the usage of raw mode is to allow flashing images
that do not respect the standard NAND page layout or the default ECC
config (this is the case on Allwinner platforms, where the ROM code
tests several hardcoded configs, which are not necessarily matching the
NAND characteristics).

Add an extension to the nand write.raw command allowing one to disable
the verification step.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 cmd/nand.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/cmd/nand.c b/cmd/nand.c
index 583a18f..3a5e3a0 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -306,7 +306,7 @@ static void nand_print_and_set_info(int idx)
 }
 
 static int raw_access(struct mtd_info *mtd, ulong addr, loff_t off,
- ulong count, int read)
+ ulong count, int read, int noverify)
 {
int ret = 0;
 
@@ -324,7 +324,7 @@ static int raw_access(struct mtd_info *mtd, ulong addr, 
loff_t off,
ret = mtd_read_oob(mtd, off, );
} else {
ret = mtd_write_oob(mtd, off, );
-   if (!ret)
+   if (!ret && !no_verify)
ret = nand_verify_page_oob(mtd, , off);
}
 
@@ -546,6 +546,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
ulong pagecount = 1;
int read;
int raw = 0;
+   int no_verify = 0;
 
if (argc < 4)
goto usage;
@@ -557,9 +558,12 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
s = strchr(cmd, '.');
 
-   if (s && !strcmp(s, ".raw")) {
+   if (s && !strncmp(s, ".raw", 4)) {
raw = 1;
 
+   if (!strcmp(s, ".raw.noverify"))
+   no_verify = 1;
+
if (mtd_arg_off(argv[3], , , , ,
MTD_DEV_TYPE_NAND,
nand_info[dev]->size))
@@ -633,7 +637,8 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
else
ret = mtd_write_oob(mtd, off, );
} else if (raw) {
-   ret = raw_access(mtd, addr, off, pagecount, read);
+   ret = raw_access(mtd, addr, off, pagecount, read,
+no_verify);
} else {
printf("Unknown nand command suffix '%s'.\n", s);
return 1;
@@ -758,7 +763,7 @@ static char nand_help_text[] =
"read/write 'size' bytes starting at offset 'off'\n"
"to/from memory address 'addr', skipping bad blocks.\n"
"nand read.raw - addr off|partition [count]\n"
-   "nand write.raw - addr off|partition [count]\n"
+   "nand write.raw[.noverify] - addr off|partition [count]\n"
"Use read.raw/write.raw to avoid ECC and access the flash as-is.\n"
 #ifdef CONFIG_CMD_NAND_TRIMFFS
"nand write.trimffs - addr off|partition size\n"
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH] ARM: sunxi/dt: make the CHIP inherit from allwinner,sun5i-a13

2016-06-14 Thread Boris Brezillon
The sun4i-timer driver registers its sched_clock only if the machine is
compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or
"allwinner,sun4i-a10".
Add the missing "allwinner,sun5i-a13" string to the machine compatible.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index 751b1a8..5273c15 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -52,7 +52,7 @@
 
 / {
model = "NextThing C.H.I.P.";
-   compatible = "nextthing,chip", "allwinner,sun5i-r8";
+   compatible = "nextthing,chip", "allwinner,sun5i-r8", 
"allwinner,sun5i-a13";
 
aliases {
i2c0 = 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-06-09 Thread Boris Brezillon
Hi Siarhei,

On Fri, 10 Jun 2016 01:07:45 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:

> On Wed, 1 Jun 2016 14:54:24 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > On Wed, 1 Jun 2016 14:41:36 +0300
> > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> >   
> > > On Mon, 30 May 2016 19:02:13 +0200
> > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > 
> > > > On Mon, 30 May 2016 19:46:17 +0300
> > > > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> > > >   
> > > > > On Mon, 30 May 2016 17:24:16 +0200
> > > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > > > 
> > > > > > Hi Hans,
> > > > > > 
> > > > > > On Mon, 30 May 2016 17:12:53 +0200
> > > > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > > > >   
> > > > > > > Generating raw NAND images is particularly useful for boot0 images
> > > > > > > creation since the mainline driver is not supporting the funky 
> > > > > > > layout
> > > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND.
> > > > > > > 
> > > > > > > This tools also allows one to generate raw images for 'normal' 
> > > > > > > partitions
> > > > > > > so that they can be flashed before soldering on the NAND on the 
> > > > > > > board
> > > > > > > (using a regular NAND programmer).
> > > > > > > 
> > > > > > > The tool takes care of generating ECC bytes and randomizing data 
> > > > > > > as
> > > > > > > expected by the NAND controller, and re-arranging the ECC/data 
> > > > > > > sections
> > > > > > > correctly.
> > > > > > 
> > > > > > Don't know how you want to proceed regarding NAND SPL image 
> > > > > > creation in
> > > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in
> > > > > > u-boot or provide a macro to pass the sunxi-tools binaries path
> > > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools
> > > > > > installed on his build platform.
> > > > > > 
> > > > > > Note that we'll need extra padding/concatenation steps to build an 
> > > > > > SPL
> > > > > > image suitable for MLC NANDs.  
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I guess, it is not a big secret that I'm also working on the SPI flash
> > > > > boot support at the moment. And some information about the progress is
> > > > > available here:
> > > > > 
> > > > > https://linux-sunxi.org/Bootable_SPI_flash
> > > > > 
> > > > > IMHO one of the most important requirements is to ensure that the 
> > > > > device
> > > > > can be always unbricked by the end users in a very simple way. That's
> > > > > why I have added the SPI flash programming feature to the sunxi-fel
> > > > > tool and it is available in a wip branch since about a week ago:
> > > > > 
> > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip
> > > > > 
> > > > > There is still some work left to do. For example, just having SPI
> > > > > flash read/write functionality (which already works btw) is not
> > > > > good enough because it is not sufficiently foolproof. There will
> > > > > be a dedicated high level "spiflash-program" commmand to flash
> > > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot.
> > > > > We had discussed this a bit on the IRC earlier:
> > > > > 
> > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894;
> > > > > 
> > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin
> > > > > image to automatically add some redundancy (two copies of the SPL):
> > > > > 
> > > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations
> > > > > And al

[linux-sunxi] [PATCH v2 1/6] sunxi: Add missing macros to configure the NAND controller clk

2016-06-08 Thread Boris Brezillon
We need some macros to manipulate the NAND controller clock.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 0088bb9..d1c5ad0 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -269,6 +269,11 @@ struct sunxi_ccm_reg {
 #define CCM_MBUS_CTRL_CLK_SRC_PLL5 0x2
 #define CCM_MBUS_CTRL_GATE (0x1 << 31)
 
+#define CCM_NAND_CTRL_M(x) ((x) - 1)
+#define CCM_NAND_CTRL_N(x) ((x) << 16)
+#define CCM_NAND_CTRL_OSCM24   (0x0 << 24)
+#define CCM_NAND_CTRL_PLL6 (0x1 << 24)
+#define CCM_NAND_CTRL_PLL5 (0x2 << 24)
 #define CCM_NAND_CTRL_ENABLE   (0x1 << 31)
 
 #define CCM_MMC_CTRL_M(x)  ((x) - 1)
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 5/6] mtd: nand: Add a full-id entry for the H27QCG8T2E5R‐BCF NAND

2016-06-08 Thread Boris Brezillon
Add a full-id entry for the H27QCG8T2E5R‐BCF NAND.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/nand_ids.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 561d2cd..ce0a14e 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -62,6 +62,10 @@ struct nand_flash_dev nand_flash_ids[] = {
{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
  SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
  NAND_ECC_INFO(40, SZ_1K), 4 },
+   {"H27QCG8T2E5R‐BCF 64G 3.3V 8-bit",
+   { .id = {0xad, 0xde, 0x14, 0xa7, 0x42, 0x4a} },
+ SZ_16K, SZ_8K, SZ_4M, NAND_NEED_SCRAMBLING, 6, 1664,
+ NAND_ECC_INFO(56, SZ_1K), 1 },
 
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 2/6] mtd: nand: add common DT init code

2016-06-08 Thread Boris Brezillon
From: Brian Norris <computersforpe...@gmail.com>

These are already-documented common bindings for NAND chips. Let's
handle them in nand_base.

If NAND controller drivers need to act on this data before bringing up
the NAND chip (e.g., fill out ECC callback functions, change HW modes,
etc.), then they can do so between calling nand_scan_ident() and
nand_scan_tail().

The original commit has been slightly reworked to use the fdtdec_xxx()
helpers (instead of the of_() ones).

Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/nand_base.c | 70 
 include/linux/mtd/nand.h |  3 ++
 2 files changed, 73 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 74c563c..c72ff86 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -29,6 +29,9 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -3764,6 +3767,66 @@ ident_done:
return type;
 }
 
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+DECLARE_GLOBAL_DATA_PTR;
+
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+{
+   int ret, ecc_mode = -1, ecc_strength, ecc_step;
+   const void *blob = gd->fdt_blob;
+   const char *str;
+
+   ret = fdtdec_get_int(blob, node, "nand-bus-width", -1);
+   if (ret == 16)
+   chip->options |= NAND_BUSWIDTH_16;
+
+   if (fdtdec_get_bool(blob, node, "nand-on-flash-bbt"))
+   chip->bbt_options |= NAND_BBT_USE_FLASH;
+
+   str = fdt_getprop(blob, node, "nand-ecc-mode", NULL);
+   if (str) {
+   if (!strcmp(str, "none"))
+   ecc_mode = NAND_ECC_NONE;
+   else if (!strcmp(str, "soft"))
+   ecc_mode = NAND_ECC_SOFT;
+   else if (!strcmp(str, "hw"))
+   ecc_mode = NAND_ECC_HW;
+   else if (!strcmp(str, "hw_syndrome"))
+   ecc_mode = NAND_ECC_HW_SYNDROME;
+   else if (!strcmp(str, "hw_oob_first"))
+   ecc_mode = NAND_ECC_HW_OOB_FIRST;
+   else if (!strcmp(str, "soft_bch"))
+   ecc_mode = NAND_ECC_SOFT_BCH;
+   }
+
+
+   ecc_strength = fdtdec_get_int(blob, node, "nand-ecc-strength", -1);
+   ecc_step = fdtdec_get_int(blob, node, "nand-ecc-step-size", -1);
+
+   if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
+   (!(ecc_step >= 0) && ecc_strength >= 0)) {
+   pr_err("must set both strength and step size in DT\n");
+   return -EINVAL;
+   }
+
+   if (ecc_mode >= 0)
+   chip->ecc.mode = ecc_mode;
+
+   if (ecc_strength >= 0)
+   chip->ecc.strength = ecc_strength;
+
+   if (ecc_step > 0)
+   chip->ecc.size = ecc_step;
+
+   return 0;
+}
+#else
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+{
+   return 0;
+}
+#endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
+
 /**
  * nand_scan_ident - [NAND Interface] Scan for the NAND device
  * @mtd: MTD device structure
@@ -3780,6 +3843,13 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
int i, nand_maf_id, nand_dev_id;
struct nand_chip *chip = mtd_to_nand(mtd);
struct nand_flash_dev *type;
+   int ret;
+
+   if (chip->flash_node) {
+   ret = nand_dt_init(mtd, chip, chip->flash_node);
+   if (ret)
+   return ret;
+   }
 
/* Set the default functions */
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b5a02c3..29aae43 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -590,6 +590,7 @@ struct nand_buffers {
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
  * flash device.
+ * @flash_node:[BOARDSPECIFIC] device node describing this 
instance
  * @read_byte: [REPLACEABLE] read one byte from the chip
  * @read_word: [REPLACEABLE] read one word from the chip
  * @write_byte:[REPLACEABLE] write a single byte to the chip 
on the
@@ -689,6 +690,8 @@ struct nand_chip {
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
+   int flash_node;
+
uint8_t (*read_byte)(struct mtd_info *mtd);
u16 (*read_word)(struct mtd_info *mtd);
void (*write_byte)(struct mtd_info *mtd,

[linux-sunxi] [PATCH v2 3/6] mtd: nand: Add the sunxi NAND controller driver

2016-06-08 Thread Boris Brezillon
We already have an SPL driver for the sunxi NAND controller, now add
the normal/standard one.

The source has been copied from Linux 4.6 with a few changes to make
it work in u-boot.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 board/sunxi/board.c|5 +-
 drivers/mtd/nand/Kconfig   |8 +-
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/sunxi_nand.c  | 1845 
 include/configs/sunxi-common.h |2 +
 include/fdtdec.h   |1 +
 include/nand.h |3 +
 lib/fdtdec.c   |1 +
 8 files changed, 1862 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mtd/nand/sunxi_nand.c

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 3cf3614..a0f4334 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -142,7 +142,7 @@ void dram_init_banksize(void)
 }
 #endif
 
-#if defined(CONFIG_NAND_SUNXI) && defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_NAND_SUNXI)
 static void nand_pinmux_setup(void)
 {
unsigned int pin;
@@ -179,6 +179,9 @@ void board_nand_init(void)
 {
nand_pinmux_setup();
nand_clock_setup();
+#ifndef CONFIG_SPL_BUILD
+   sunxi_nand_init();
+#endif
 }
 #endif
 
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8c46a2f..5ce7d6d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -64,12 +64,14 @@ config NAND_PXA3XX
  PXA3xx processors (NFCv1) and also on Armada 370/XP (NFCv2).
 
 config NAND_SUNXI
-   bool "Support for NAND on Allwinner SoCs in SPL"
+   bool "Support for NAND on Allwinner SoCs"
depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
select SYS_NAND_SELF_INIT
---help---
-   Enable support for NAND. This option allows SPL to read from
-   sunxi NAND using DMA transfers.
+   Enable support for NAND. This option enables the standard and
+   SPL drivers.
+   The SPL driver only supports reading from the NAND using DMA
+   transfers.
 
 config NAND_ARASAN
bool "Configure Arasan Nand"
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 837d397..1df9273 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_NAND) += tegra_nand.o
 obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
+obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
 
 else  # minimal SPL drivers
 
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
new file mode 100644
index 000..c4e2cd7
--- /dev/null
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -0,0 +1,1845 @@
+/*
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon@gmail.com>
+ * Copyright (C) 2015 Roy Spliet <r.spl...@ultimaker.com>
+ *
+ * Derived from:
+ * https://github.com/yuq/sunxi-nfc-mtd
+ * Copyright (C) 2013 Qiang Yu <yuq...@gmail.com>
+ *
+ * https://github.com/hno/Allwinner-Info
+ * Copyright (C) 2013 Henrik Nordström 
+ *
+ * Copyright (C) 2013 Dmitriy B. <rzk...@gmail.com>
+ * Copyright (C) 2013 Sergey Lapin <sla...@ossfans.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define NFC_REG_CTL0x
+#define NFC_REG_ST 0x0004
+#define NFC_REG_INT0x0008
+#define NFC_REG_TIMING_CTL 0x000C
+#define NFC_REG_TIMING_CFG 0x0010
+#define NFC_REG_ADDR_LOW   0x0014
+#define NFC_REG_ADDR_HIGH  0x0018
+#define NFC_REG_SECTOR_NUM 0x001C
+#define NFC_REG_CNT0x0020
+#define NFC_REG_CMD0x0024
+#define NFC_REG_RCMD_SET   0x0028
+#define NFC_REG_WCMD_SET   0x002C
+#define NFC_REG_IO_DATA0x0030
+#define NFC_REG_ECC_CTL0x0034
+#define NFC_REG_ECC_ST 0x0038
+#define NFC_REG_DEBUG  0x003C
+#define NFC_REG_ECC_ERR_CNT(x) ((0x0040 + (x)) & ~0x3)
+#define NFC_REG_USER_DATA(x)   (0x0050 + ((x) * 4))
+#define NFC_REG_SPARE_AREA 0x00A0
+#define NFC_REG_PAT_ID 0x00A4
+#define NFC_RAM0_BASE  0x0400
+#define NFC_RAM1_BASE  0x0800
+
+/* define bit use in NFC_CTL */
+#

[linux-sunxi] [PATCH v2 4/6] sun5i: Add NAND controller to the sun5i DTSI

2016-06-08 Thread Boris Brezillon
From: Maxime Ripard <maxime.rip...@free-electrons.com>

Add the NAND controller definition to sun5i.dtsi.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 arch/arm/dts/sun5i.dtsi | 49 +
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/dts/sun5i.dtsi b/arch/arm/dts/sun5i.dtsi
index 59a9426..87e5353 100644
--- a/arch/arm/dts/sun5i.dtsi
+++ b/arch/arm/dts/sun5i.dtsi
@@ -356,6 +356,17 @@
#dma-cells = <2>;
};
 
+   nfc: nand@01c03000 {
+   compatible = "allwinner,sun4i-a10-nand";
+   reg = <0x01c03000 0x1000>;
+   interrupts = <37>;
+   clocks = <_gates 13>, <_clk>;
+   clock-names = "ahb", "mod";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
spi0: spi@01c05000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c05000 0x1000>;
@@ -548,6 +559,44 @@
allwinner,pull = ;
};
 
+   nand_pins_a: nand_base0@0 {
+   allwinner,pins = "PC0", "PC1", "PC2",
+   "PC5", "PC8", "PC9", "PC10",
+   "PC11", "PC12", "PC13", "PC14",
+   "PC15";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_cs0_pins_a: nand_cs@0 {
+   allwinner,pins = "PC4";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_cs1_pins_a: nand_cs@1 {
+   allwinner,pins = "PC3";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_rb0_pins_a: nand_rb@0 {
+   allwinner,pins = "PC6";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_rb1_pins_a: nand_rb@1 {
+   allwinner,pins = "PC7";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
uart3_pins_a: uart3@0 {
allwinner,pins = "PG9", "PG10";
allwinner,function = "uart3";
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 6/6] sunxi: Enable NAND controller on the CHIP

2016-06-08 Thread Boris Brezillon
Enable the NAND controller in the sun5i-r8-chip.dts.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 arch/arm/dts/sun5i-a10s.dtsi | 14 ++
 arch/arm/dts/sun5i-a13-olinuxino.dts | 15 +++
 arch/arm/dts/sun5i-r8-chip.dts   | 15 +++
 3 files changed, 44 insertions(+)

diff --git a/arch/arm/dts/sun5i-a10s.dtsi b/arch/arm/dts/sun5i-a10s.dtsi
index bddd0de..a5f8855 100644
--- a/arch/arm/dts/sun5i-a10s.dtsi
+++ b/arch/arm/dts/sun5i-a10s.dtsi
@@ -241,6 +241,20 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   nand_cs2_pins_a: nand_cs@2 {
+   allwinner,pins = "PC17";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_cs3_pins_a: nand_cs@3 {
+   allwinner,pins = "PC18";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
 };
 
 _a {
diff --git a/arch/arm/dts/sun5i-a13-olinuxino.dts 
b/arch/arm/dts/sun5i-a13-olinuxino.dts
index b3c234c..30e069a 100644
--- a/arch/arm/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/dts/sun5i-a13-olinuxino.dts
@@ -155,6 +155,21 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _cs0_pins_a _rb0_pins_a>;
+   status = "okay";
+
+   nand@0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0>;
+   allwinner,rb = <0>;
+   nand-ecc-mode = "hw";
+   allwinner,randomize;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/sun5i-r8-chip.dts b/arch/arm/dts/sun5i-r8-chip.dts
index 6ad19e2..b1b62d5 100644
--- a/arch/arm/dts/sun5i-r8-chip.dts
+++ b/arch/arm/dts/sun5i-r8-chip.dts
@@ -142,6 +142,21 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _cs0_pins_a _rb0_pins_a>;
+   status = "okay";
+
+   nand@0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0>;
+   allwinner,rb = <0>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

2016-06-06 Thread Boris Brezillon
On Mon, 6 Jun 2016 22:31:38 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> On Mon, 6 Jun 2016 22:59:03 +0300
> Aleksei Mamlin <mamli...@gmail.com> wrote:
> 
> > On Mon, 6 Jun 2016 20:55:49 +0200
> > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> >   
> > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > Aleksei Mamlin <mamli...@gmail.com> wrote:
> > > 
> > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > timings
> > > > mode in controller drivers.
> > > 
> > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > not the case, I'll apply your patch.
> > > 
> > > BTW, that would be great if you could test it on your platforms.
> > > 
> > 
> > It seems that Hynix-specific initialization code can't handle 
> > H27UBG8T2BTR-BC
> > chip:
> > 
> > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > [0.899025] nand: Hynix 1c03000.nand
> > [0.902596] nand: bus width 8 instead 16 bit
> > [0.906858] nand: No NAND device found
> > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> 
> Can you try this patch? It should fix the problem [1].

Brian, I have a question regarding the extended NAND ids (not full-ids)
defined in the nand_ids table. Are they really valid for all vendors?

If that's the case, why are we extracting the bus width from the id[3]
since we already have this information in the options field?

> 
> [1]http://code.bulix.org/6hjww1-100494
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

2016-06-06 Thread Boris Brezillon
On Tue, 7 Jun 2016 00:06:45 +0300
Aleksei Mamlin <mamli...@gmail.com> wrote:

> On Mon, 6 Jun 2016 22:31:38 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > On Mon, 6 Jun 2016 22:59:03 +0300
> > Aleksei Mamlin <mamli...@gmail.com> wrote:
> >   
> > > On Mon, 6 Jun 2016 20:55:49 +0200
> > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > >   
> > > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > > Aleksei Mamlin <mamli...@gmail.com> wrote:
> > > > 
> > > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > > timings
> > > > > mode in controller drivers.
> > > > 
> > > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > > not the case, I'll apply your patch.
> > > > 
> > > > BTW, that would be great if you could test it on your platforms.
> > > > 
> > > 
> > > It seems that Hynix-specific initialization code can't handle 
> > > H27UBG8T2BTR-BC
> > > chip:
> > > 
> > > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > > [0.899025] nand: Hynix 1c03000.nand
> > > [0.902596] nand: bus width 8 instead 16 bit
> > > [0.906858] nand: No NAND device found
> > > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> > 
> > Can you try this patch? It should fix the problem [1].
> > 
> > [1]http://code.bulix.org/6hjww1-100494
> >   
> 
> Yes, it fixes problem. What about ONFI parameter page? Should it be ignored?

It should be ignored: your NAND is not 'ONFI compatible', the datasheet
just says that it supports the' ONFI command set', which is not the
same :).
The trace you're seeing here is just notifying that the core failed to
detect an ONFI NAND, which is expected in your case.

> [0.886068] nand: Could not find valid ONFI parameter page; aborting
> [0.892571] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> [0.898917] nand: Hynix NAND 4GiB 3,3V 8-bit
> [0.903198] nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, 
> OOB size: 640
> [0.911908] Bad block table found at page 524032, version 0x01
> [0.918534] Bad block table found at page 523776, version 0x01
> [0.972112] 5 ofpart partitions found on MTD device 1c03000.nand
> [0.978116] Creating 5 MTD partitions on "1c03000.nand":
> [    0.983477] 0x-0x0020 : "boot0"
> [0.988803] 0x0020-0x0040 : "boot0-rescue"
> [0.994692] 0x0040-0x0060 : "uboot"
> [0.44] 0x0060-0x0080 : "uboot-rescue"
> [1.005763] 0x0080-0x0001 : "main"
> 
> > 
> > -- 
> > Boris Brezillon, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com  
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver

2016-06-06 Thread Boris Brezillon
On Mon, 06 Jun 2016 18:54:03 -0500
Scott Wood <o...@buserror.net> wrote:

> On Mon, 2016-06-06 at 20:31 +0200, Boris Brezillon wrote:
> > On Mon, 06 Jun 2016 12:56:48 -0500
> > Scott Wood <o...@buserror.net> wrote:
> >   
> > > On Mon, 2016-06-06 at 18:22 +0200, Boris Brezillon wrote:  
> > > > On Mon, 6 Jun 2016 17:36:10 +0200
> > > > Hans de Goede <hdego...@redhat.com> wrote:
> > > > 
> > > > > > +#ifndef CONFIG_SPL_BUILD
> > > > > > +void sunxi_nand_init(void);
> > > > > > +#endif
> > > > > > +  
> > > > > 
> > > > > Can we have this in a header somewhere please, and without
> > > > > the #ifdef around it, that is not necessary for prototypes.
> > > > 
> > > > Hehe, I was expecting this one :-). Do you know where I should put this
> > > > prototype definition? A board.h file in board/sunxi/?
> > > 
> > > It's defined in drivers/mtd/nand and called from board/sunxi so the
> > > prototype
> > > needs to go somewhere under include/.  It can go in include/configs/sunxi
> > > -common.h with #ifndef __ASSEMBLY__ around it -- or as long as it's
> > > limited to
> > > one init func per driver, maybe we could just put it in include/nand.h.  
> > 
> > Hm, none of these solutions seem ideal.
> > 
> > Maybe we could define a generic void nand_controller_init(void)
> > prototype so that we don't need to add new xxx_nand_init() functions for
> > platforms needing this 2 steps initialization (platform specific pinmux
> > + clocks config before NAND controller initialization).
> > 
> > Otherwise, I think I'll go for the 2nd solution (defining
> > sunxi_nand_init() in include/nand.h).  
> 
> I'd prefer not having a generic nand_controller_init() because some platforms
> may want to pass arguments, plus I don't want to rule out the possibility of
> two different NAND controller types being supported at once.
> 
> include/nand.h is fine with me, as long as any driver than wants more than an
> initfunc moves its stuff into a dedicated header.

Sure.

> Of course the driver model
> is probably the long-term solution.

Definitely, and talking about things that need to be reworked, do you
know why u-boot is using its own MTD partition infrastructure instead
of relying on mtdpart.c?
That's really a pain when one wants to add a new feature (like
definitions of partitions in the DT, or SLC mode on MLC NANDs) because
he has to do it twice.

And that's not the only inconsistent part in the MTD/NAND layer IMO.
MTD is providing a generic abstraction for all flashes, but nand_util
is still directly accessing the NAND layer instead of going through the
MTD abstraction.
By using the MTD abstraction everywhere (I mean for all flash devices),
we could provide generic utils (flash erase, flash write), even if
specific tools might be needed in a few cases.

Anyway, good to hear that you plan to switch to the driver model.

Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

2016-06-06 Thread Boris Brezillon
On Mon, 6 Jun 2016 22:59:03 +0300
Aleksei Mamlin <mamli...@gmail.com> wrote:

> On Mon, 6 Jun 2016 20:55:49 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > On Mon,  6 Jun 2016 13:24:22 +0300
> > Aleksei Mamlin <mamli...@gmail.com> wrote:
> >   
> > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > timings
> > > mode in controller drivers.  
> > 
> > Still hoping to get this series [1] merged in 4.8, but if that's
> > not the case, I'll apply your patch.
> > 
> > BTW, that would be great if you could test it on your platforms.
> >   
> 
> It seems that Hynix-specific initialization code can't handle H27UBG8T2BTR-BC
> chip:
> 
> [0.886153] nand: Could not find valid ONFI parameter page; aborting
> [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> [0.899025] nand: Hynix 1c03000.nand
> [0.902596] nand: bus width 8 instead 16 bit
> [0.906858] nand: No NAND device found
> [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22

Can you try this patch? It should fix the problem [1].

[1]http://code.bulix.org/6hjww1-100494


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

2016-06-06 Thread Boris Brezillon
On Mon,  6 Jun 2016 13:24:22 +0300
Aleksei Mamlin <mamli...@gmail.com> wrote:

> Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> nand_ids table so that we can later use the NAND ECC infos and ONFI timings
> mode in controller drivers.

Still hoping to get this series [1] merged in 4.8, but if that's
not the case, I'll apply your patch.

BTW, that would be great if you could test it on your platforms.

Regards,

Boris

[1]https://lkml.org/lkml/2016/5/27/264

> 
> Signed-off-by: Aleksei Mamlin <mamli...@gmail.com>
> ---
>  drivers/mtd/nand/nand_ids.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index ccc05f5..ccdc773 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -52,6 +52,10 @@ struct nand_flash_dev nand_flash_ids[] = {
>   { .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
> SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
> NAND_ECC_INFO(40, SZ_1K), 4 },
> + {"H27UBG8T2BTR-BC 32G 3.3V 8-bit",
> + { .id = {0xad, 0xd7, 0x94, 0xda, 0x74, 0xc3} },
> +   SZ_8K, SZ_4K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
> +   NAND_ECC_INFO(40, SZ_1K), 0 },
>  
>   LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
>   LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 7/7] ARM: dts: sun7i: Enable NAND on Wexler TAB7200

2016-06-06 Thread Boris Brezillon
On Mon,  6 Jun 2016 13:24:24 +0300
Aleksei Mamlin <mamli...@gmail.com> wrote:

> Enable the NFC and describe the NAND flash connected to this controller.
> 
> Signed-off-by: Aleksei Mamlin <mamli...@gmail.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 41 
> ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts 
> b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> index 2f6b21a..42aff91 100644
> --- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> @@ -159,6 +159,47 @@
>   status = "okay";
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>, <_cs0_pins_a>, <_rb0_pins_a>;
> + status = "okay";
> +
> + nand@0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0>;
> + allwinner,rb = <0>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + boot0@0 {
> + label = "boot0";
> + reg = /bits/ 64 <0x0 0x20>;
> + };
> +
> + boot0-rescue@20 {
> + label = "boot0-rescue";
> + reg = /bits/ 64 <0x20 0x20>;
> + };
> +
> + uboot@40 {
> + label = "uboot";
> + reg = /bits/ 64 <0x40 0x20>;
> + };
> +
> + uboot-rescue@60 {
> + label = "uboot-rescue";
> + reg = /bits/ 64 <0x60 0x20>;
> + };
> +
> + main@80 {
> + label = "main";
> + reg = /bits/ 64 <0x80 0xff80>;
> + };
> + };
> +};
> +
>   {
>   status = "okay";
>  };



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 6/7] ARM: dts: sun4i: Enable NAND on Marsboard A10

2016-06-06 Thread Boris Brezillon
On Mon,  6 Jun 2016 13:24:23 +0300
Aleksei Mamlin <mamli...@gmail.com> wrote:

> Enable the NFC and describe the NAND flash connected to this controller.
> 
> Signed-off-by: Aleksei Mamlin <mamli...@gmail.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  arch/arm/boot/dts/sun4i-a10-marsboard.dts | 41 
> +++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10-marsboard.dts 
> b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> index 8e50723..ea6e2d5 100644
> --- a/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> @@ -150,6 +150,47 @@
>   status = "okay";
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>, <_cs0_pins_a>, <_rb0_pins_a>;
> + status = "okay";
> +
> + nand@0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0>;
> + allwinner,rb = <0>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + boot0@0 {
> + label = "boot0";
> + reg = /bits/ 64 <0x0 0x20>;
> + };
> +
> + boot0-rescue@20 {
> + label = "boot0-rescue";
> + reg = /bits/ 64 <0x20 0x20>;
> + };
> +
> + uboot@40 {
> + label = "uboot";
> + reg = /bits/ 64 <0x40 0x20>;
> + };
> +
> + uboot-rescue@60 {
> + label = "uboot-rescue";
> + reg = /bits/ 64 <0x60 0x20>;
> + };
> +
> + main@80 {
> + label = "main";
> + reg = /bits/ 64 <0x80 0xff80>;
> + };
> + };
> +};
> +
>   {
>   status = "okay";
>  };



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver

2016-06-06 Thread Boris Brezillon
On Mon, 06 Jun 2016 12:56:48 -0500
Scott Wood <o...@buserror.net> wrote:

> On Mon, 2016-06-06 at 18:22 +0200, Boris Brezillon wrote:
> > On Mon, 6 Jun 2016 17:36:10 +0200
> > Hans de Goede <hdego...@redhat.com> wrote:
> >   
> > > > +#ifndef CONFIG_SPL_BUILD
> > > > +void sunxi_nand_init(void);
> > > > +#endif
> > > > +
> > > 
> > > Can we have this in a header somewhere please, and without
> > > the #ifdef around it, that is not necessary for prototypes.  
> > 
> > Hehe, I was expecting this one :-). Do you know where I should put this
> > prototype definition? A board.h file in board/sunxi/?  
> 
> It's defined in drivers/mtd/nand and called from board/sunxi so the prototype
> needs to go somewhere under include/.  It can go in include/configs/sunxi
> -common.h with #ifndef __ASSEMBLY__ around it -- or as long as it's limited to
> one init func per driver, maybe we could just put it in include/nand.h.

Hm, none of these solutions seem ideal.

Maybe we could define a generic void nand_controller_init(void)
prototype so that we don't need to add new xxx_nand_init() functions for
platforms needing this 2 steps initialization (platform specific pinmux
+ clocks config before NAND controller initialization).

Otherwise, I think I'll go for the 2nd solution (defining
sunxi_nand_init() in include/nand.h).

Let me know what you prefer.

Thanks,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v3 1/2] mtd: nand: sunxi: add support for DMA assisted operations

2016-06-06 Thread Boris Brezillon
On Fri, 15 Apr 2016 15:10:30 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> The sunxi NAND controller is able to pipeline ECC operations only when
> operated in DMA mode, which improves a lot NAND throughput while keeping
> CPU usage low.

Applied both.

> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> Changes since v2:
> - completely drop the generic approach base on Russell's feedback
>   (doing DMA on non-lowmem memory is unsafe)
> - fix a bug in sunxi_nfc_hw_ecc_read_chunks_dma() where the ECC status
>   value was lost when at least one bitflip was found in an erased chunk
> 
> Changes since v1:
> - reworked sg_alloc_table_from_buf() to avoid splitting contiguous
>   vmalloced area
> - fixed a bug in the read_dma()
> - fixed dma_direction flag in write_dma()
> 
>  drivers/mtd/nand/sunxi_nand.c | 330 
> +-
>  1 file changed, 323 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 1baf8983..5299ab0 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -153,6 +153,7 @@
>  
>  /* define bit use in NFC_ECC_ST */
>  #define NFC_ECC_ERR(x)   BIT(x)
> +#define NFC_ECC_ERR_MSK  GENMASK(15, 0)
>  #define NFC_ECC_PAT_FOUND(x) BIT(x + 16)
>  #define NFC_ECC_ERR_CNT(b, x)(((x) >> (((b) % 4) * 8)) & 0xff)
>  
> @@ -273,6 +274,7 @@ struct sunxi_nfc {
>   unsigned long clk_rate;
>   struct list_head chips;
>   struct completion complete;
> + struct dma_chan *dmac;
>  };
>  
>  static inline struct sunxi_nfc *to_sunxi_nfc(struct nand_hw_control *ctrl)
> @@ -365,6 +367,67 @@ static int sunxi_nfc_rst(struct sunxi_nfc *nfc)
>   return ret;
>  }
>  
> +static int sunxi_nfc_dma_op_prepare(struct mtd_info *mtd, const void *buf,
> + int chunksize, int nchunks,
> + enum dma_data_direction ddir,
> + struct scatterlist *sg)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
> + struct dma_async_tx_descriptor *dmad;
> + enum dma_transfer_direction tdir;
> + dma_cookie_t dmat;
> + int ret;
> +
> + if (ddir == DMA_FROM_DEVICE)
> + tdir = DMA_DEV_TO_MEM;
> + else
> + tdir = DMA_MEM_TO_DEV;
> +
> + sg_init_one(sg, buf, nchunks * chunksize);
> + ret = dma_map_sg(nfc->dev, sg, 1, ddir);
> + if (!ret)
> + return -ENOMEM;
> +
> + dmad = dmaengine_prep_slave_sg(nfc->dmac, sg, 1, tdir, DMA_CTRL_ACK);
> + if (IS_ERR(dmad)) {
> + ret = PTR_ERR(dmad);
> + goto err_unmap_buf;
> + }
> +
> + writel(readl(nfc->regs + NFC_REG_CTL) | NFC_RAM_METHOD,
> +nfc->regs + NFC_REG_CTL);
> + writel(nchunks, nfc->regs + NFC_REG_SECTOR_NUM);
> + writel(chunksize, nfc->regs + NFC_REG_CNT);
> + dmat = dmaengine_submit(dmad);
> +
> + ret = dma_submit_error(dmat);
> + if (ret)
> + goto err_clr_dma_flag;
> +
> + return 0;
> +
> +err_clr_dma_flag:
> + writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
> +nfc->regs + NFC_REG_CTL);
> +
> +err_unmap_buf:
> + dma_unmap_sg(nfc->dev, sg, 1, ddir);
> + return ret;
> +}
> +
> +static void sunxi_nfc_dma_op_cleanup(struct mtd_info *mtd,
> +  enum dma_data_direction ddir,
> +  struct scatterlist *sg)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
> +
> + dma_unmap_sg(nfc->dev, sg, 1, ddir);
> + writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
> +nfc->regs + NFC_REG_CTL);
> +}
> +
>  static int sunxi_nfc_dev_ready(struct mtd_info *mtd)
>  {
>   struct nand_chip *nand = mtd_to_nand(mtd);
> @@ -822,17 +885,15 @@ static void sunxi_nfc_hw_ecc_update_stats(struct 
> mtd_info *mtd,
>  }
>  
>  static int sunxi_nfc_hw_ecc_correct(struct mtd_info *mtd, u8 *data, u8 *oob,
> - int step, bool *erased)
> + int step, u32 status, bool *erased)
>  {
>   struct nand_chip *nand = mtd_to_nand(mtd);
>   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
>   struct nand_ecc_ctrl *ecc = >ecc;
> - u32 status, tmp;
> + u32 tmp;
> 

[linux-sunxi] [PATCH 6/6] sunxi: Enable NAND controller on the CHIP

2016-06-06 Thread Boris Brezillon
Enable the NAND controller in the sun5i-r8-chip.dts.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 arch/arm/dts/sun5i-a10s.dtsi | 14 ++
 arch/arm/dts/sun5i-a13-olinuxino.dts | 15 +++
 arch/arm/dts/sun5i-r8-chip.dts   | 15 +++
 3 files changed, 44 insertions(+)

diff --git a/arch/arm/dts/sun5i-a10s.dtsi b/arch/arm/dts/sun5i-a10s.dtsi
index bddd0de..a5f8855 100644
--- a/arch/arm/dts/sun5i-a10s.dtsi
+++ b/arch/arm/dts/sun5i-a10s.dtsi
@@ -241,6 +241,20 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   nand_cs2_pins_a: nand_cs@2 {
+   allwinner,pins = "PC17";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   nand_cs3_pins_a: nand_cs@3 {
+   allwinner,pins = "PC18";
+   allwinner,function = "nand0";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
 };
 
 _a {
diff --git a/arch/arm/dts/sun5i-a13-olinuxino.dts 
b/arch/arm/dts/sun5i-a13-olinuxino.dts
index b3c234c..30e069a 100644
--- a/arch/arm/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/dts/sun5i-a13-olinuxino.dts
@@ -155,6 +155,21 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _cs0_pins_a _rb0_pins_a>;
+   status = "okay";
+
+   nand@0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0>;
+   allwinner,rb = <0>;
+   nand-ecc-mode = "hw";
+   allwinner,randomize;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/sun5i-r8-chip.dts b/arch/arm/dts/sun5i-r8-chip.dts
index 6ad19e2..b1b62d5 100644
--- a/arch/arm/dts/sun5i-r8-chip.dts
+++ b/arch/arm/dts/sun5i-r8-chip.dts
@@ -142,6 +142,21 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _cs0_pins_a _rb0_pins_a>;
+   status = "okay";
+
+   nand@0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0>;
+   allwinner,rb = <0>;
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 5/6] mtd: nand: Add a full-id entry for the H27QCG8T2E5R‐BCF NAND

2016-06-06 Thread Boris Brezillon
Add a full-id entry for the H27QCG8T2E5R‐BCF NAND.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/nand_ids.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 561d2cd..ce0a14e 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -62,6 +62,10 @@ struct nand_flash_dev nand_flash_ids[] = {
{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
  SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
  NAND_ECC_INFO(40, SZ_1K), 4 },
+   {"H27QCG8T2E5R‐BCF 64G 3.3V 8-bit",
+   { .id = {0xad, 0xde, 0x14, 0xa7, 0x42, 0x4a} },
+ SZ_16K, SZ_8K, SZ_4M, NAND_NEED_SCRAMBLING, 6, 1664,
+ NAND_ECC_INFO(56, SZ_1K), 1 },
 
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 0/6] sunxi: Add NAND controller driver

2016-06-06 Thread Boris Brezillon
Hello,

This patch series is adding the normal sunxi NAND controller driver to
u-boot.

It's based on the Linux driver, with a few adaptions to make it work
in Linux.

It's based on Scott's series syncing the MTD/NAND frameworks with
Linux 4.6 [1].

Best Regards,

Boris

[1]https://patchwork.ozlabs.org/patch/627928/

Boris Brezillon (4):
  sunxi: Add missing macros to configure the NAND controller clk
  mtd: nand: Add the sunxi NAND controller driver
  mtd: nand: Add a full-id entry for the H27QCG8T2E5R‐BCF NAND
  sunxi: Enable NAND controller on the CHIP

Brian Norris (1):
  mtd: nand: add common DT init code

Maxime Ripard (1):
  sun5i: Add NAND controller to the sun5i DTSI

 arch/arm/dts/sun5i-a10s.dtsi  |   14 +
 arch/arm/dts/sun5i-a13-olinuxino.dts  |   15 +
 arch/arm/dts/sun5i-r8-chip.dts|   15 +
 arch/arm/dts/sun5i.dtsi   |   49 +
 arch/arm/include/asm/arch-sunxi/clock_sun4i.h |5 +
 board/sunxi/board.c   |9 +-
 drivers/mtd/nand/Kconfig  |8 +-
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/nand_base.c  |   70 +
 drivers/mtd/nand/nand_ids.c   |4 +
 drivers/mtd/nand/sunxi_nand.c | 1845 +
 include/configs/sunxi-common.h|2 +
 include/fdtdec.h  |1 +
 include/linux/mtd/nand.h  |3 +
 lib/fdtdec.c  |1 +
 15 files changed, 2038 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mtd/nand/sunxi_nand.c

-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 2/6] mtd: nand: add common DT init code

2016-06-06 Thread Boris Brezillon
From: Brian Norris <computersforpe...@gmail.com>

These are already-documented common bindings for NAND chips. Let's
handle them in nand_base.

If NAND controller drivers need to act on this data before bringing up
the NAND chip (e.g., fill out ECC callback functions, change HW modes,
etc.), then they can do so between calling nand_scan_ident() and
nand_scan_tail().

The original commit has been slightly reworked to use the fdtdec_xxx()
helpers (instead of the of_() ones).

Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 70 
 include/linux/mtd/nand.h |  3 ++
 2 files changed, 73 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 74c563c..c72ff86 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -29,6 +29,9 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -3764,6 +3767,66 @@ ident_done:
return type;
 }
 
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+DECLARE_GLOBAL_DATA_PTR;
+
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+{
+   int ret, ecc_mode = -1, ecc_strength, ecc_step;
+   const void *blob = gd->fdt_blob;
+   const char *str;
+
+   ret = fdtdec_get_int(blob, node, "nand-bus-width", -1);
+   if (ret == 16)
+   chip->options |= NAND_BUSWIDTH_16;
+
+   if (fdtdec_get_bool(blob, node, "nand-on-flash-bbt"))
+   chip->bbt_options |= NAND_BBT_USE_FLASH;
+
+   str = fdt_getprop(blob, node, "nand-ecc-mode", NULL);
+   if (str) {
+   if (!strcmp(str, "none"))
+   ecc_mode = NAND_ECC_NONE;
+   else if (!strcmp(str, "soft"))
+   ecc_mode = NAND_ECC_SOFT;
+   else if (!strcmp(str, "hw"))
+   ecc_mode = NAND_ECC_HW;
+   else if (!strcmp(str, "hw_syndrome"))
+   ecc_mode = NAND_ECC_HW_SYNDROME;
+   else if (!strcmp(str, "hw_oob_first"))
+   ecc_mode = NAND_ECC_HW_OOB_FIRST;
+   else if (!strcmp(str, "soft_bch"))
+   ecc_mode = NAND_ECC_SOFT_BCH;
+   }
+
+
+   ecc_strength = fdtdec_get_int(blob, node, "nand-ecc-strength", -1);
+   ecc_step = fdtdec_get_int(blob, node, "nand-ecc-step-size", -1);
+
+   if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
+   (!(ecc_step >= 0) && ecc_strength >= 0)) {
+   pr_err("must set both strength and step size in DT\n");
+   return -EINVAL;
+   }
+
+   if (ecc_mode >= 0)
+   chip->ecc.mode = ecc_mode;
+
+   if (ecc_strength >= 0)
+   chip->ecc.strength = ecc_strength;
+
+   if (ecc_step > 0)
+   chip->ecc.size = ecc_step;
+
+   return 0;
+}
+#else
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+{
+   return 0;
+}
+#endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
+
 /**
  * nand_scan_ident - [NAND Interface] Scan for the NAND device
  * @mtd: MTD device structure
@@ -3780,6 +3843,13 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
int i, nand_maf_id, nand_dev_id;
struct nand_chip *chip = mtd_to_nand(mtd);
struct nand_flash_dev *type;
+   int ret;
+
+   if (chip->flash_node) {
+   ret = nand_dt_init(mtd, chip, chip->flash_node);
+   if (ret)
+   return ret;
+   }
 
/* Set the default functions */
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b5a02c3..29aae43 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -590,6 +590,7 @@ struct nand_buffers {
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
  * flash device.
+ * @flash_node:[BOARDSPECIFIC] device node describing this 
instance
  * @read_byte: [REPLACEABLE] read one byte from the chip
  * @read_word: [REPLACEABLE] read one word from the chip
  * @write_byte:[REPLACEABLE] write a single byte to the chip 
on the
@@ -689,6 +690,8 @@ struct nand_chip {
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
+   int flash_node;
+
uint8_t (*read_byte)(struct mtd_info *mtd);
u16 (*read_word)(struct mtd_info *mtd);
void (*write_byte)(struct mtd_info *mtd, uint8_t byte);
-- 
2.7.4

-- 
You received this mess

[linux-sunxi] [PATCH 1/6] sunxi: Add missing macros to configure the NAND controller clk

2016-06-06 Thread Boris Brezillon
We some macro to manipulate the NAND controller clock.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 0088bb9..d1c5ad0 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -269,6 +269,11 @@ struct sunxi_ccm_reg {
 #define CCM_MBUS_CTRL_CLK_SRC_PLL5 0x2
 #define CCM_MBUS_CTRL_GATE (0x1 << 31)
 
+#define CCM_NAND_CTRL_M(x) ((x) - 1)
+#define CCM_NAND_CTRL_N(x) ((x) << 16)
+#define CCM_NAND_CTRL_OSCM24   (0x0 << 24)
+#define CCM_NAND_CTRL_PLL6 (0x1 << 24)
+#define CCM_NAND_CTRL_PLL5 (0x2 << 24)
 #define CCM_NAND_CTRL_ENABLE   (0x1 << 31)
 
 #define CCM_MMC_CTRL_M(x)  ((x) - 1)
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 3/3] mtd: nand: sunxi: fix subpage write

2016-06-06 Thread Boris Brezillon
On Mon,  6 Jun 2016 13:59:14 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

Oops, I forgot to add this commit message:

"
Implement ecc->write_subpage() to prevent core code from assigning
this hook to nand_write_subpage_hwecc(). This default implementation
tries to call ecc->hwctl() which in our case is NULL, thus leading
to a NULL pointer dereference.
"

> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
>  drivers/mtd/nand/sunxi_nand.c | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 252cbbf..409acbe 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -1350,6 +1350,36 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info 
> *mtd,
>   return 0;
>  }
>  
> +static int sunxi_nfc_hw_ecc_write_subpage(struct mtd_info *mtd,
> +   struct nand_chip *chip,
> +   u32 data_offs, u32 data_len,
> +   const u8 *buf, int oob_required,
> +   int page)
> +{
> + struct nand_ecc_ctrl *ecc = >ecc;
> + int ret, i, cur_off = 0;
> +
> + sunxi_nfc_hw_ecc_enable(mtd);
> +
> + for (i = data_offs / ecc->size;
> +  i < DIV_ROUND_UP(data_offs + data_len, ecc->size); i++) {
> + int data_off = i * ecc->size;
> + int oob_off = i * (ecc->bytes + 4);
> + const u8 *data = buf + data_off;
> + const u8 *oob = chip->oob_poi + oob_off;
> +
> + ret = sunxi_nfc_hw_ecc_write_chunk(mtd, data, data_off, oob,
> +oob_off + mtd->writesize,
> +_off, !i, page);
> + if (ret)
> + return ret;
> + }
> +
> + sunxi_nfc_hw_ecc_disable(mtd);
> +
> + return 0;
> +}
> +
>  static int sunxi_nfc_hw_ecc_write_page_dma(struct mtd_info *mtd,
>  struct nand_chip *chip,
>  const u8 *buf,
> @@ -1862,7 +1892,8 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info 
> *mtd,
>   ecc->write_page = sunxi_nfc_hw_ecc_write_page;
>   }
>  
> - /* TODO: support DMA for raw accesses */
> + /* TODO: support DMA for raw accesses and subpage write */
> + ecc->write_subpage = sunxi_nfc_hw_ecc_write_subpage;
>   ecc->read_oob_raw = nand_read_oob_std;
>   ecc->write_oob_raw = nand_write_oob_std;
>   ecc->read_subpage = sunxi_nfc_hw_ecc_read_subpage;



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 1/3] mtd: nand: sunxi: prefer 1k ECC blocks when applicable

2016-06-06 Thread Boris Brezillon
Switching to 1k ECC blocks when possible provides better resistance against
concentrated bitflips. Say you have those two configurations:

1/ 16bits/512bytes
2/ 32bits/1024bytes

Both of them require the same amount of ECC bytes (only true for this
specific engine), but the second config allows you to correct the case
where most of your bitflips are concentrated in a single 512bytes portion.

This fact makes the 1k ECC block size more advantageous than the 512bytes
one.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 5299ab0..4f5b4ad 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1784,6 +1784,12 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct 
mtd_info *mtd,
if (!data)
return -ENOMEM;
 
+   /* Prefer 1k ECC chunk over 512 ones */
+   if (ecc->size == 512 && mtd->writesize > 512) {
+   ecc->size = 1024;
+   ecc->strength *= 2;
+   }
+
/* Add ECC info retrieval from DT */
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
if (ecc->strength <= strengths[i])
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 0/3] mtd: nand: sunxi: fix SLC NAND support

2016-06-06 Thread Boris Brezillon
Hello,

Those 3 patches aims a fixing support for SLC NANDs with rather small
NAND pages (<= 4k).

The first patch promote 512 bytes ECC steps to 1k steps, which should
both save a few OOB bytes and provide stronger ECC.
The second patch checks the ECC step value, and rejects any NAND that
requires ECC steps != 512 | 1024.
The last patch implements ecc->write_subpage(), thus fixing a NULL
pointer dereference when the NAND chip supports subpage write.

Best Regards,

Boris

Boris Brezillon (3):
  mtd: nand: sunxi: prefer 1k ECC blocks when applicable
  mtd: nand: sunxi: check ecc->size values
  mtd: nand: sunxi: fix subpage write

 drivers/mtd/nand/sunxi_nand.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 2/3] mtd: nand: sunxi: check ecc->size values

2016-06-06 Thread Boris Brezillon
Verify that the ecc->size value is either 512 or 1024 bytes.
This should always be the case if this field was assigned to the
nand->ecc_step_size_ds value, but can be wrong when the user overloaded
this value with the nand-ecc-step-size DT property.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 4f5b4ad..252cbbf 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1784,6 +1784,9 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct 
mtd_info *mtd,
if (!data)
return -ENOMEM;
 
+   if (ecc->size != 512 && ecc->size != 1024)
+   return -EINVAL;
+
/* Prefer 1k ECC chunk over 512 ones */
if (ecc->size == 512 && mtd->writesize > 512) {
ecc->size = 1024;
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 3/3] mtd: nand: sunxi: fix subpage write

2016-06-06 Thread Boris Brezillon
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 252cbbf..409acbe 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1350,6 +1350,36 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info 
*mtd,
return 0;
 }
 
+static int sunxi_nfc_hw_ecc_write_subpage(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ u32 data_offs, u32 data_len,
+ const u8 *buf, int oob_required,
+ int page)
+{
+   struct nand_ecc_ctrl *ecc = >ecc;
+   int ret, i, cur_off = 0;
+
+   sunxi_nfc_hw_ecc_enable(mtd);
+
+   for (i = data_offs / ecc->size;
+i < DIV_ROUND_UP(data_offs + data_len, ecc->size); i++) {
+   int data_off = i * ecc->size;
+   int oob_off = i * (ecc->bytes + 4);
+   const u8 *data = buf + data_off;
+   const u8 *oob = chip->oob_poi + oob_off;
+
+   ret = sunxi_nfc_hw_ecc_write_chunk(mtd, data, data_off, oob,
+  oob_off + mtd->writesize,
+  _off, !i, page);
+   if (ret)
+   return ret;
+   }
+
+   sunxi_nfc_hw_ecc_disable(mtd);
+
+   return 0;
+}
+
 static int sunxi_nfc_hw_ecc_write_page_dma(struct mtd_info *mtd,
   struct nand_chip *chip,
   const u8 *buf,
@@ -1862,7 +1892,8 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info 
*mtd,
ecc->write_page = sunxi_nfc_hw_ecc_write_page;
}
 
-   /* TODO: support DMA for raw accesses */
+   /* TODO: support DMA for raw accesses and subpage write */
+   ecc->write_subpage = sunxi_nfc_hw_ecc_write_subpage;
ecc->read_oob_raw = nand_read_oob_std;
ecc->write_oob_raw = nand_write_oob_std;
ecc->read_subpage = sunxi_nfc_hw_ecc_read_subpage;
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v4 2/4] nand-image-builder: Add error messages to check_image_info()

2016-06-06 Thread Boris Brezillon
Add error messages explaining what is wrong or missing in the arguments
passed by to the sunxi-nand-image-builder tool.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortm...@web.de>
---
Changes since v1:
- Drop uneeded braces
---
 nand-image-builder.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index a5fb3d8..465ab36 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -941,20 +941,37 @@ static int check_image_info(struct image_info *info)
int eccbytes, eccsteps;
unsigned i;
 
-   if (!info->page_size || !info->oob_size || !info->eraseblock_size ||
-   !info->usable_page_size)
+   if (!info->page_size) {
+   fprintf(stderr, "--page-size is missing\n");
return -EINVAL;
+   }
+
+   if (!info->page_size) {
+   fprintf(stderr, "--oob-size is missing\n");
+   return -EINVAL;
+   }
+
+   if (!info->eraseblock_size) {
+   fprintf(stderr, "--eraseblock-size is missing\n");
+   return -EINVAL;
+   }
 
-   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024)
+   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024) {
+   fprintf(stderr, "Invalid ECC step argument: %d\n",
+   info->ecc_step_size);
return -EINVAL;
+   }
 
for (i = 0; i < ARRAY_SIZE(valid_ecc_strengths); i++) {
if (valid_ecc_strengths[i] == info->ecc_strength)
break;
}
 
-   if (i == ARRAY_SIZE(valid_ecc_strengths))
+   if (i == ARRAY_SIZE(valid_ecc_strengths)) {
+   fprintf(stderr, "Invalid ECC strength argument: %d\n",
+   info->ecc_strength);
return -EINVAL;
+   }
 
eccbytes = DIV_ROUND_UP(info->ecc_strength * 14, 8);
if (eccbytes % 2)
@@ -964,8 +981,11 @@ static int check_image_info(struct image_info *info)
eccsteps = info->usable_page_size / info->ecc_step_size;
 
if (info->page_size + info->oob_size <
-   info->usable_page_size + (eccsteps * (eccbytes)))
+   info->usable_page_size + (eccsteps * eccbytes)) {
+   fprintf(stderr,
+   "ECC bytes do not fit in the NAND page, choose a weaker 
ECC\n");
return -EINVAL;
+   }
 
return 0;
 }
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v4 1/4] nand-image-builder: Fix the copyright header

2016-06-06 Thread Boris Brezillon
Add NextThing Co. and Free Electrons copyrights and add myself as the
author of the randomizer and image builder implementation.

Remove the lengthy description explaining how the BCH implementation works,
since this is the purpose of this tool is not to expose a BCH library
(which was the case of the original source code I copied from the kernel).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Changes since v1:
- Add a link to the original bch.c source file
---
 nand-image-builder.c | 49 -
 1 file changed, 8 insertions(+), 41 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 645d1cc..a5fb3d8 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -14,55 +14,22 @@
  * this program; if not, write to the Free Software Foundation, Inc., 51
  * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
+ * For the BCH implementation:
+ *
  * Copyright © 2011 Parrot S.A.
  *
  * Author: Ivan Djelic <ivan.dje...@parrot.com>
  *
- * Description:
- *
- * This library provides runtime configurable encoding/decoding of binary
- * Bose-Chaudhuri-Hocquenghem (BCH) codes.
- *
- * Call init_bch to get a pointer to a newly allocated bch_control structure 
for
- * the given m (Galois field order), t (error correction capability) and
- * (optional) primitive polynomial parameters.
- *
- * Call encode_bch to compute and store ecc parity bytes to a given buffer.
- * Call decode_bch to detect and locate errors in received data.
- *
- * On systems supporting hw BCH features, intermediate results may be provided
- * to decode_bch in order to skip certain steps. See decode_bch() documentation
- * for details.
- *
- * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
- * parameters m and t; thus allowing extra compiler optimizations and providing
- * better (up to 2x) encoding performance. Using this option makes sense when
- * (m,t) are fixed and known in advance, e.g. when using BCH error correction
- * on a particular NAND flash device.
- *
- * Algorithmic details:
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
  *
- * Encoding is performed by processing 32 input bits in parallel, using 4
- * remainder lookup tables.
+ * For the randomizer and image builder implementation:
  *
- * The final stage of decoding involves the following internal steps:
- * a. Syndrome computation
- * b. Error locator polynomial computation using Berlekamp-Massey algorithm
- * c. Error locator root finding (by far the most expensive step)
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
  *
- * In this implementation, step c is not performed using the usual Chien 
search.
- * Instead, an alternative approach described in [1] is used. It consists in
- * factoring the error locator polynomial using the Berlekamp Trace algorithm
- * (BTA) down to a certain degree (4), after which ad hoc low-degree polynomial
- * solving techniques [2] are used. The resulting algorithm, called BTZ, yields
- * much better performance than Chien search for usual (m,t) values (typically
- * m >= 13, t < 32, see [1]).
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
  *
- * [1] B. Biswas, V. Herbert. Efficient root finding of polynomials over fields
- * of characteristic 2, in: Western European Workshop on Research in Cryptology
- * - WEWoRC 2009, Graz, Austria, LNCS, Springer, July 2009, to appear.
- * [2] [Zin96] V.A. Zinoviev. On the solution of equations of degree 10 over
- * finite fields GF(2^q). In Rapport de recherche INRIA no 2829, 1996.
  */
 
 #include 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v4 4/4] nand-image-builder: Fix --help/-h option

2016-06-06 Thread Boris Brezillon
--help/-h is not working correctly (it's printing the help context on
stderr instead of stdout).
Adding a valid shortcut for --help solves the problem.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortm...@web.de>
---
 nand-image-builder.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 41e559f..0ca2d14 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -1032,7 +1032,7 @@ int main(int argc, char **argv)
int option_index = 0;
char *endptr = NULL;
static const struct option long_options[] = {
-   {"help", no_argument, 0, 0},
+   {"help", no_argument, 0, 'h'},
{"ecc", required_argument, 0, 'c'},
{"page", required_argument, 0, 'p'},
{"oob", required_argument, 0, 'o'},
@@ -1044,7 +1044,7 @@ int main(int argc, char **argv)
{0, 0, 0, 0},
};
 
-   int c = getopt_long(argc, argv, "c:p:o:u:e:ba:s",
+   int c = getopt_long(argc, argv, "c:p:o:u:e:ba:sh",
long_options, _index);
if (c == EOF)
break;
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v4 3/4] nand-image-builder: Rework the help context

2016-06-06 Thread Boris Brezillon
Add explanations on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortm...@web.de>
---
Changes since v3:
- cosmetic changes to the help context

Changes since v2:
- limit line width in the help context

Changes since v1:
- use shorter option names
- rework the help context
---
 nand-image-builder.c | 70 +---
 1 file changed, 50 insertions(+), 20 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 465ab36..41e559f 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -917,21 +917,51 @@ static void display_help(int status)
 {
fprintf(status == EXIT_SUCCESS ? stdout : stderr,
"Usage: sunxi-nand-image-builder [OPTIONS] source-image 
output-image\n"
+   "\n"
"Creates a raw NAND image that can be read by the sunxi NAND 
controller.\n"
"\n"
-   "-h --help  Display 
this help and exit\n"
-   "-c /   --ecc=/ ECC 
config\n"
-   "   Valid 
strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
-   "   Valid 
steps: 512 and 1024\n"
-   "-p   --page-size=  Page 
size\n"
-   "-o   --oob-size=   OOB 
size\n"
-   "-u   --usable-page-size=   Usable 
page size. Only needed for boot0 mode\n"
-   "-e   --eraseblock-size=Erase 
block size\n"
-   "-b --boot0 Build a 
boot0 image.\n"
-   "-s --scramble  
Scramble data\n"
-   "-a --address   Where 
the image will be programmed.\n"
-   "   This 
option is only required for non boot0 images that are meant to be programmed at 
a non eraseblock aligned offset.\n"
-   "\n");
+   "-h   --help   Display this help and 
exit\n"
+   "-c /  --ecc=/   ECC config 
(strength/step-size)\n"
+   "-p --page=Page size\n"
+   "-o --oob= OOB size\n"
+   "-u --usable=  Usable page size\n"
+   "-e --eraseblock=  Erase block size\n"
+   "-b   --boot0  Build a boot0 image.\n"
+   "-s   --scramble   Scramble data\n"
+   "-a   --address=   Where the image will be 
programmed.\n"
+   "\n"
+   "Notes:\n"
+   "All the information you need to pass to this tool should be 
part of\n"
+   "the NAND datasheet.\n"
+   "\n"
+   "The NAND controller only supports the following ECC configs\n"
+   "  Valid ECC strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
+   "  Valid ECC step size: 512 and 1024\n"
+   "\n"
+   "If you are building a boot0 image, you'll have specify extra 
options.\n"
+   "These options should be chosen based on the layouts described 
here:\n"
+   "  http://linux-sunxi.org/NAND#More_information_on_BROM_NAND\n;
+   "\n"
+   "  --usable should be assigned the 'Hardware page' value\n"
+   "  --ecc should be assigned the 'ECC capacity'/'ECC page' 
values\n"
+   "  --usable should be smaller than --page\n"
+   "\n"
+   "The --address option is only required for non-boot0 images 
that are \n"
+   "meant to be programmed at a non eraseblock aligned offset.\n"
+   "\n"
+   "Examples:\n"
+   "  The H27UCG8T2BTR-BC NAND exposes\n"
+   "  * 16k pages\n"
+   "  * 1280 OOB bytes per page\n"
+   "  * 4M eraseblocks\n"
+   "  * requires data scrambling\n"
+   "  * expects a minimum ECC of 40bits/1024bytes\n"
+   "\n"
+   "  A 

[linux-sunxi] [PATCH v3 1/7] spl: nand: sunxi: remove support for so-called 'syndrome' mode

2016-06-06 Thread Boris Brezillon
The sunxi SPL NAND controller driver supports use 'BootROM'-like configs,
that is, configs where the ECC bytes and real data are interleaved in the
page instead of putting ECC bytes in the OOB area.

Doing that has several drawbacks:
- since you're interleaving data and ECC bytes you can't use the whole page
  otherwise you might override the bad block marker with non-FF bytes.
- to solve the bad block marker problem, the ROM code supports partially
  using the page, but this introduces a huge penalty both in term of read
  speed and NAND memory usage. While this is fine for rather small
  binaries(like the SPL one which is at maximum 24KB large), it becomes
  non-negligible for the bootloader image (several hundred of KB).
- auto-detection of the page size is not reliable (this is in my opinion
  the biggest problem). If you get the page size wrong, you'll end up
  reading data at a different offset than what was specified by the caller
  and the reading may succeed (if valid data were written at this address).

For all those reasons I think it's wiser to completely remove support for
'syndrome' configs. If we ever need to support it again, then I'd recommend
specifying all the config parameters through Kconfig options.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 56 ++-
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b0e07aa..1739da2 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,9 +119,6 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-/* random seed used for syndrome calls */
-const uint16_t random_seed_syndrome = 0x4a80;
-
 #define MAX_RETRIES 10
 
 static int check_value_inner(int offset, int expected_bits,
@@ -183,7 +180,7 @@ void nand_init(void)
 }
 
 static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -209,17 +206,11 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
page = real_addr / page_size;
column = real_addr % page_size;
 
-   if (syndrome)
-   column += (column / ecc_page_size) * ecc_off;
-
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   if (syndrome)
-   rand_seed = random_seed_syndrome;
-   else
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % 128];
 
writel((rand_seed << 16) | NFC_ECC_RANDOM_EN | NFC_ECC_EN
| NFC_ECC_PIPELINE | (ecc_mode << 12),
@@ -228,9 +219,8 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome)
-   writel(page_size + (column / ecc_page_size) * ecc_off,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
@@ -266,7 +256,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
NFC_PAGE_CMD | NFC_WAIT_FLAG |
((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
-   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
+   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
@@ -292,7 +282,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
 }
 
 static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest, int syndrome)
+   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
 {
void *end = dest + size;
 
@@ -301,16 +291,14 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 
for ( ;dest < end; dest += ecc_page_size, offs += ecc_page_size) {
if (nand_read_page(page_size, ecc_strength, ecc_page_size,
-  addr_cycles, offs, (dma_addr_t)dest,
-  syndrome))
+  addr_cycles, offs, (dma_addr_t)dest))
return -1;
}
 
return 0;

[linux-sunxi] [PATCH v3 3/7] spl: nand: support redundant u-boot image

2016-06-06 Thread Boris Brezillon
On modern NAND it's more than recommended to have a backup copy of the
u-boot binary to recover from corruption: bitflips are quite common on
MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
more quickly than what you would see on an SLC NAND.

Add an extra Kconfig option to specify the offset of the redundant u-boot
image.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>

# Conflicts:
#   common/spl/spl_nand.c
#   drivers/mtd/nand/Kconfig
---
 common/spl/spl_nand.c| 5 +
 drivers/mtd/nand/Kconfig | 8 
 2 files changed, 13 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index bbd9546..d8c5b9e 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -107,6 +107,11 @@ int spl_nand_load_image(void)
 #endif
/* Load u-boot */
err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
+#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
+   if (err)
+   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
+   header);
+#endif
nand_deselect();
return err;
 }
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5fe169f..8c46a2f 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -117,6 +117,14 @@ config SYS_NAND_U_BOOT_OFFS
Set the offset from the start of the nand where u-boot should be
loaded from.
 
+config SYS_NAND_U_BOOT_OFFS_REDUND
+   hex "Location in NAND to read U-Boot from"
+   default SYS_NAND_U_BOOT_OFFS
+   depends on SYS_NAND_U_BOOT_LOCATIONS
+   help
+   Set the offset from the start of the nand where the redundant u-boot
+   should be loaded from.
+
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
help
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v3 4/7] spl: nand: sunxi: stop guessing the redundant u-boot offset

2016-06-06 Thread Boris Brezillon
Use CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND value instead of trying to guess
where the redundant u-boot image is based on simple (and most of the time
erroneous) heuristics.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>

# Conflicts:
#   drivers/mtd/nand/sunxi_nand_spl.c
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 1739da2..13e6eab 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -344,26 +344,6 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest)
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
-   /*
-* u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
-* for backup u-boot 1 erase block further.
-*/
-   const uint32_t eraseblock_size = CONFIG_SYS_NAND_U_BOOT_OFFS / 2;
-   const uint32_t boot_offsets[] = {
-   CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_U_BOOT_OFFS + eraseblock_size,
-   };
-   int i;
-
-   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
-   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
-   if (nand_read_buffer(boot_offsets[i], size,
-dest) == 0)
-   return 0;
-   }
-   return -1;
-   }
-
return nand_read_buffer(offs, size, dest);
 }
 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v3 6/7] spl: nand: sunxi: split 'load page' and 'read page' logic

2016-06-06 Thread Boris Brezillon
Split the 'load page' and 'read page' logic in 2 different functions so
we can later load the page and test different ECC configs without the
penalty of reloading the same page in the NAND cache.

We also move common setup to a dedicated function (nand_apply_config()) to
avoid rewriting the same values in NFC registers each time we read a page.

These new functions are passed a pointer to an nfc_config struct to limit
the number of parameters.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 185 +++---
 1 file changed, 114 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 55b3c8a..b43f2af 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -66,6 +66,8 @@
 #define NFC_ROW_AUTO_INC   (1 << 27)
 #define NFC_SEND_CMD3  (1 << 28)
 #define NFC_SEND_CMD4  (1 << 29)
+#define NFC_RAW_CMD(0 << 30)
+#define NFC_PAGE_CMD   (2 << 30)
 
 #define NFC_ST_CMD_INT_FLAG(1 << 1)
 #define NFC_ST_DMA_INT_FLAG(1 << 2)
@@ -78,9 +80,6 @@
 #define NFC_CMD_RNDOUT 0x05
 #define NFC_CMD_READSTART  0x30
 
-
-#define NFC_PAGE_CMD   (2 << 30)
-
 #define SUNXI_DMA_CFG_REG0  0x300
 #define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
 #define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
@@ -97,6 +96,15 @@
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
 
+struct nfc_config {
+   int page_size;
+   int ecc_strength;
+   int ecc_size;
+   int addr_cycles;
+   int nseeds;
+   bool randomize;
+};
+
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
 /* random seed used by linux */
@@ -175,50 +183,70 @@ void nand_init(void)
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 }
 
-static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
+static void nand_apply_config(const struct nfc_config *conf)
 {
-   uint32_t val;
-   int i, ecc_off = 0;
-   uint16_t ecc_mode = 0;
-   uint16_t rand_seed;
-   uint32_t page;
-   uint16_t column;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+   u32 val;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   ecc_mode = i;
-   break;
-   }
+   val = readl(SUNXI_NFC_BASE + NFC_CTL);
+   val &= ~NFC_CTL_PAGE_SIZE_MASK;
+   writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
+  SUNXI_NFC_BASE + NFC_CTL);
+   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
+   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
+}
+
+static int nand_load_page(const struct nfc_config *conf, u32 offs)
+{
+   int page = offs / conf->page_size;
+
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(((page & 0x) << 16), SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
+   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
+  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -EIO;
}
 
-   /* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
-   /* HW ECC always work with even numbers of ECC bytes */
-   ecc_off += (ecc_off & 1);
-   ecc_off += 4; /* prepad */
+   return 0;
+}
+
+static int nand_read_page(const struct nfc_config *conf, u32 offs,
+ void *dest, int len)
+{
+   dma_addr_t dst = (dma_addr_t)dest;
+   int nsectors = len / conf->ecc_size;
+   u16 rand_seed;
+   u32 val;
+   int page;
+
+   page = offs / conf->page_size;
 
-   page = real_addr / page_size;
-   column = real_addr % page_size;
+   if (offs % conf->page_size || len % conf->ecc_size ||
+   len > conf->page_size || len < 0)
+   

[linux-sunxi] [PATCH v3 5/7] spl: nand: sunxi: rework status polling loop

2016-06-06 Thread Boris Brezillon
check_value_xxx() helpers are using a 1ms delay between each test, which
can be quite long for some operations (like a page read on an SLC NAND).
Since we don't have anything to do but to poll this register, reduce the
delay between each test to 1us.

While we're at it, rename the max_number_of_retries parameters and the
MAX_RETRIES macro into timeout_us and DEFAULT_TIMEOUT_US to reflect that
we're actually waiting a given amount of time and not only a number of
retries.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 13e6eab..55b3c8a 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,35 +119,31 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-#define MAX_RETRIES 10
+#define DEFAULT_TIMEOUT_US 10
 
 static int check_value_inner(int offset, int expected_bits,
-   int max_number_of_retries, int negation)
+int timeout_us, int negation)
 {
-   int retries = 0;
do {
int val = readl(offset) & expected_bits;
if (negation ? !val : val)
return 1;
-   mdelay(1);
-   retries++;
-   } while (retries < max_number_of_retries);
+   udelay(1);
+   } while (--timeout_us);
 
return 0;
 }
 
 static inline int check_value(int offset, int expected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, expected_bits,
-   max_number_of_retries, 0);
+   return check_value_inner(offset, expected_bits, timeout_us, 0);
 }
 
 static inline int check_value_negated(int offset, int unexpected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, unexpected_bits,
-   max_number_of_retries, 1);
+   return check_value_inner(offset, unexpected_bits, timeout_us, 1);
 }
 
 void nand_init(void)
@@ -162,7 +158,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CTL);
 
if (!check_value_negated(SUNXI_NFC_BASE + NFC_CTL,
-NFC_CTL_RESET, MAX_RETRIES)) {
+NFC_CTL_RESET, DEFAULT_TIMEOUT_US)) {
printf("Couldn't initialize nand\n");
}
 
@@ -172,7 +168,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error timeout waiting for nand reset\n");
return;
}
@@ -260,14 +256,15 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error while initializing dma interrupt\n");
return -1;
}
writel(NFC_ST_DMA_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
-SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
+SUNXI_DMA_DDMA_CFG_REG_LOADING,
+DEFAULT_TIMEOUT_US)) {
printf("Error while waiting for dma transfer to finish\n");
return -1;
}
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v3 2/7] spl: nand: rework SYS_NAND_U_BOOT_OFFS Kconfig option dependency

2016-06-06 Thread Boris Brezillon
The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
to explicitly depend on platforms that are not already defining it in their
include/configs/.h header.

Add the SYS_NAND_U_BOOT_LOCATIONS option, make the SYS_NAND_U_BOOT_OFFS
depends on it, remove the dependency on NAND_SUNXI and make it dependent
on SPL selection.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/Kconfig | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2fc73ef..5fe169f 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -99,17 +99,24 @@ config SYS_NAND_BUSWIDTH_16BIT
not available while configuring controller. So a static 
CONFIG_NAND_xx
is needed to know the device's bus-width in advance.
 
-# Enhance depends when converting drivers to Kconfig which use this config
+if SPL
+
+config SYS_NAND_U_BOOT_LOCATIONS
+   bool "Define U-boot binaries locations in NAND"
+   help
+   Enable CONFIG_SYS_NAND_U_BOOT_OFFS though Kconfig.
+   This option should not be enabled when compiling U-boot for boards
+   defining CONFIG_SYS_NAND_U_BOOT_OFFS in their include/configs/.h
+   file.
+
 config SYS_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
-   depends on NAND_SUNXI
+   depends on SYS_NAND_U_BOOT_LOCATIONS
help
Set the offset from the start of the nand where u-boot should be
loaded from.
 
-if SPL
-
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
help
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v3 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-06-06 Thread Boris Brezillon
NAND chips are supposed to expose their capabilities through advanced
mechanisms like READID, ONFI or JEDEC parameter tables. While those
methods are appropriate for the bootloader itself, it's way to
complicated and takes too much space to fit in the SPL.

Replace those mechanisms by a dumb 'trial and error' mechanism.

With this new approach we can get rid of the fixed config list that was
used in the sunxi NAND SPL driver.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
Changes since v1:
- fix the nand_max_ecc_strength()
---
 drivers/mtd/nand/sunxi_nand_spl.c | 262 +-
 1 file changed, 204 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b43f2af..1ef7366 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -103,6 +103,7 @@ struct nfc_config {
int addr_cycles;
int nseeds;
bool randomize;
+   bool valid;
 };
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
@@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
u32 offs)
return 0;
 }
 
+static int nand_reset_column(void)
+{
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
+  (1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static int nand_read_page(const struct nfc_config *conf, u32 offs,
  void *dest, int len)
 {
@@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config *conf, 
u32 offs,
return (val & 0x1) ? 1 : 0;
 }
 
-static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
+static int nand_max_ecc_strength(struct nfc_config *conf)
 {
-   void *end = dest + size;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
-   struct nfc_config conf = {
-   .page_size = page_size,
-   .ecc_size = ecc_page_size,
-   .addr_cycles = addr_cycles,
-   .nseeds = ARRAY_SIZE(random_seed),
-   .randomize = true,
-   };
+   static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
};
+   int max_oobsize, max_ecc_bytes;
+   int nsectors = conf->page_size / conf->ecc_size;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   conf.ecc_strength = i;
+   /*
+* ECC strength is limited by the size of the OOB area which is
+* correlated with the page size.
+*/
+   switch (conf->page_size) {
+   case 2048:
+   max_oobsize = 64;
+   break;
+   case 4096:
+   max_oobsize = 256;
+   break;
+   case 8192:
+   max_oobsize = 640;
+   break;
+   case 16384:
+   max_oobsize = 1664;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   max_ecc_bytes = max_oobsize / nsectors;
+
+   for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
+   if (ecc_bytes[i] > max_ecc_bytes)
break;
-   }
}
 
+   if (!i)
+   return -EINVAL;
 
-   nand_apply_config();
+   return i - 1;
+}
 
-   for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
-   if (nand_load_page(, offs))
-   return -1;
+static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
+ void *dest)
+{
+   /* NAND with pages > 4k will likely require 1k sector size. */
+   int min_ecc_size = conf->page_size > 4096 ? 1024 : 512;
+   int page = offs / conf->page_size;
+   int ret;
 
-   if (nand_read_page(, offs, dest, page_size))
-   return -1;
+   /*
+* In most cases, 1k sectors are preferred over 512b ones, start
+* testing this config first.
+*/
+   for (conf->ecc_size = 1024; conf->ecc_size >= min_ecc_size;
+conf->ecc_size >>= 1) {
+   int max_ecc_strength = nan

[linux-sunxi] [PATCH v3 0/7] spl: nand: sunxi: implement auto-detection

2016-06-06 Thread Boris Brezillon
Hello,

This patch series aims at adding support for NAND auto-detection to
the sunxi SPL NAND driver.

As explained in patch 7, this auto-detection is nothing more than a
dumb "trial and error" logic, but it allows one to use the same
SPL binary for all kind of sunxi boards booting from NAND.
Of course, this approach might increase a bit the boot-time, but this
is something we could address by adding a "default NAND config",
that would be tested before launching the auto-detection procedure.

Now let's detail a bit what's inside this patch-set.
Patch 1 is a cleanup removing support for BootROM configs, which in
my opinion are not only inefficient but also not reliable (at least
the current implementation does not guarantee that you'll be using
the correct configuration when reading the NAND).

Piotr, Hans, any comment?
Is this a real problem if we get rid of syndrome/BootROM configs?
I mean, are you really using this mode? If that's not the case, I'd
prefer dropping support for this feature. ITOH, if you really
need this mode, then I'd recommend adding Kconfig options to specify
the exact config to be used rather than randomly testing configs
(see my explanation in patch 1).

Patch 2 is reworking the SYS_NAND_U_BOOT_OFFS Kconfig dependency model
to make it usable on all platforms (not only sunxi).

Patch 3 is adding generic support for redundant u-boot images, which
is particularly useful on modern NANDs where corruptions is likely to
happen.
Patch 4 is just getting rid of the open-coded version of redundant
u-boot image support in the sunxi NAND driver.

Patch 5 is a simple improvement of the NAND controller status polling
loop, which is really important to make the "trial and error"
approach efficient (we try to limit the impact on boot-time here).
Patch 6 and 7 are implementing the auto-detection logic.

Best Regards,

Boris

Changes since v2:
- rework the Kconfig options for SYS_U_BOOT_OFFS and
  SYS_U_BOOT_REDUND_OFFS

Changes since v1:
- added Hans ack
- fixed 2 typos in patch 7

Boris Brezillon (7):
  spl: nand: sunxi: remove support for so-called 'syndrome' mode
  spl: nand: rework SYS_NAND_U_BOOT_OFFS Kconfig option dependency
  spl: nand: support redundant u-boot image
  spl: nand: sunxi: stop guessing the redundant u-boot offset
  spl: nand: sunxi: rework status polling loop
  spl: nand: sunxi: split 'load page' and 'read page' logic
  spl: nand: sunxi: add support for NAND config auto-detection

 common/spl/spl_nand.c |   5 +
 drivers/mtd/nand/Kconfig  |  21 +-
 drivers/mtd/nand/sunxi_nand_spl.c | 480 --
 3 files changed, 332 insertions(+), 174 deletions(-)

-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

2016-06-04 Thread Boris Brezillon
On Sat, 04 Jun 2016 02:14:09 -0500
Scott Wood <o...@buserror.net> wrote:

> On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote:
> > On Fri, 03 Jun 2016 20:08:49 -0500
> > Scott Wood <o...@buserror.net> wrote:
> >  
> > > This doesn't work.  CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined
> > > when SPL is defined, and the user will be forced to enter a value before
> > > kconfig will continue (or kconfig will error out in an automated build).  
> > 
> > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be
> > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header
> > file.
> > And for the "user will forced to enter a value before Kconfig
> > continue" comment, we could just have
> > 
> > config SPL_NAND_U_BOOT_OFFS
> > hex "Location in NAND to read U-Boot from"
> > default 0x8000 if NAND_SUNXI
> > default 0x0
> > ...  
> 
> If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS from
> the header.

Nope, because the condition is

#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
#endif

and not

#ifdef CONFIG_SPL_NAND_U_BOOT_OFFS
#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
#endif

So CONFIG_SYS_NAND_U_BOOT_OFFS is always preferred over
CONFIG_SPL_NAND_U_BOOT_OFFS if it's defined.

> 
> > > If you want to do this there needs to be a separate bool config that
> > > controls whether the hex config exists.  
> > 
> > I can add an extra Kconfig option, but is it really necessary:
> > if people are relying on it they will choose a valid value, and leave
> > it to 0 otherwise.
> > It's just a detail, so I'm fine adding this extra option if you think
> > it's really useful.  
> 
> Zero *is* a valid value.  Several boards already have that value for this
> symbol.  Even if that weren't the case,  we want a mechanism for migrating
> from header value to kconfig value that works for more than just this one
> specific symbol.

Sure, 0 is a perfectly valid value. The "default 0" is just here to
prevent make from blocking because of a missing definition in the
_defconfig.

> 
> >   
> > > And there'd be no need to rename hex symbol.  
> > 
> > Well, functionally there's no problem keeping the existing SYS_ prefix
> > if we add this extra option to activate the U_OFFS config in Kconfig,
> > but I'm not sure this is a good idea to reuse config header names in
> > Kconfig.
> > 
> > And what happens if the user enabled this option (some like to enable
> > everything :-)) and CONFIG_SYS_NAND_U_BOOT_OFFS is also defined in the
> > board config header?  
> 
> Then the build fails with a redefined symbol, and the user learns their
> lesson. :-)

Fair enough.

> 
> The "SYS" in CONFIG_SYS means it's not a user-tunable knob.  From README:
> 
> > There are two classes of configuration variables:
> > 
> > * Configuration _OPTIONS_:
> >   These are selectable by the user and have names beginning with
> >   "CONFIG_".
> > 
> > * Configuration _SETTINGS_:
> >   These depend on the hardware etc. and should not be meddled with if
> >   you don't know what you're doing; they have names beginning with
> >   "CONFIG_SYS_".  

Okay. I'll switch back to SYS_NAND_U_BOOT_OFFS, add an intermediate
option to unlock this one in the config menu and rename
CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND into
CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v2 3/7] spl: nand: support redundant u-boot image

2016-06-04 Thread Boris Brezillon
On Fri, 03 Jun 2016 20:15:16 -0500
Scott Wood <o...@buserror.net> wrote:

> On Wed, 2016-06-01 at 13:23 +0200, Boris Brezillon wrote:
> > On modern NAND it's more than recommended to have a backup copy of the
> > u-boot binary to recover from corruption: bitflips are quite common on
> > MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
> > more quickly than what you would see on an SLC NAND.  
> 
> Wouldn't the same happen to the SPL itself?  Or is the boot block implemented
> in a different, more robust manner?

Nope, the same happens to the SPL image, and we're actually using the
same trick: the brom code search for a valid SPL image every 64
pages is duplicated every 64 pages (it tests the first 8 locations:
page 0, page 64, page 128, ..., page 448).

We usually fill 2 blocks with SPL images (repeating it several times in
each block).

> 
> > Add an extra Kconfig option to specify the offset of the redundant u-boot
> > image.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > Acked-by: Hans de Goede <hdego...@redhat.com>
> > ---
> >  common/spl/spl_nand.c| 8 
> >  drivers/mtd/nand/Kconfig | 6 ++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> > index 612bd4a..0bf0848 100644
> > --- a/common/spl/spl_nand.c
> > +++ b/common/spl/spl_nand.c
> > @@ -12,6 +12,9 @@
> >  
> >  #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
> >  #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
> > +#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
> > CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND
> > +#else
> > +#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
> >  #endif
> >  
> >  #if defined(CONFIG_SPL_NAND_RAW_ONLY)
> > @@ -111,6 +114,11 @@ int spl_nand_load_image(void)
> >  #endif
> > /* Load u-boot */
> > err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
> > +#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
> > +   if (err)
> > +   err =
> > spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
> > +   header);
> > +#endif  
> 
> If one of the images has failed, doesn't it need to be reflashed before the
> other one goes bad as well?

Yes, that's the idea.

> How does the failure get communicated to later
> parts of the system that would be responsible for such reflashing?

Linux is taking care of that (a script tries to read the u-boot
partition, and if fails it reflashes it with the content of the
u-boot-backup partition, or with a reference u-boot.bin file).
I guess u-boot could do it too.

Anyway, that's a different story ;).

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

2016-06-04 Thread Boris Brezillon
On Fri, 03 Jun 2016 20:08:49 -0500
Scott Wood <o...@buserror.net> wrote:

> On Wed, 2016-06-01 at 13:23 +0200, Boris Brezillon wrote:
> > The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
> > to explicitly depend on platforms that are not already defining it in their
> > include/configs/.h header.
> > 
> > Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency
> > on NAND_SUNXI and make it dependent on SPL selection.
> > 
> > common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to
> > CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay
> > compatible with the existing behavior.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > Acked-by: Hans de Goede <hdego...@redhat.com>
> > ---
> >  common/spl/spl_nand.c | 4 
> >  drivers/mtd/nand/Kconfig  | 9 +
> >  drivers/mtd/nand/sunxi_nand_spl.c | 8 
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> > index bbd9546..612bd4a 100644
> > --- a/common/spl/spl_nand.c
> > +++ b/common/spl/spl_nand.c
> > @@ -10,6 +10,10 @@
> >  #include 
> >  #include 
> >  
> > +#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
> > +#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
> > +#endif  
> [snip]
> > -# Enhance depends when converting drivers to Kconfig which use this config
> > -config SYS_NAND_U_BOOT_OFFS
> > +if SPL
> > +
> > +# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS.
> > +# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined.
> > +config SPL_NAND_U_BOOT_OFFS
> > hex "Location in NAND to read U-Boot from"
> > default 0x8000 if NAND_SUNXI
> > -   depends on NAND_SUNXI
> > help
> > Set the offset from the start of the nand where u-boot should be
> > loaded from.  
> 
> This doesn't work.  CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined when 
> SPL is defined, and the user will be forced to enter a value before kconfig 
> will continue (or kconfig will error out in an automated build).

Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be
used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header
file.
And for the "user will forced to enter a value before Kconfig
continue" comment, we could just have

config SPL_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
default 0x0
...

> 
> If you want to do this there needs to be a separate bool config that controls 
> whether the hex config exists.

I can add an extra Kconfig option, but is it really necessary:
if people are relying on it they will choose a valid value, and leave
it to 0 otherwise.
It's just a detail, so I'm fine adding this extra option if you think
it's really useful.

> And there'd be no need to rename hex symbol.

Well, functionally there's no problem keeping the existing SYS_ prefix
if we add this extra option to activate the U_OFFS config in Kconfig,
but I'm not sure this is a good idea to reuse config header names in
Kconfig.

And what happens if the user enabled this option (some like to enable
everything :-)) and CONFIG_SYS_NAND_U_BOOT_OFFS is also defined in the
board config header?
That's what I was trying to avoid. By renaming the Kconfig option we
make sure the value defined in include/configs/.h always take
precedence over the Kconfig value.



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v3 1/4] nand-image-builder: Fix the copyright header

2016-06-03 Thread Boris Brezillon
Add NextThing Co. and Free Electrons copyrights and add myself as the
author of the randomizer and image builder implementation.

Remove the lengthy description explaining how the BCH implementation works,
since this is the purpose of this tool is not to expose a BCH library
(which was the case of the original source code I copied from the kernel).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Changes since v1:
- Add a link to the original bch.c source file
---
 nand-image-builder.c | 49 -
 1 file changed, 8 insertions(+), 41 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 645d1cc..a5fb3d8 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -14,55 +14,22 @@
  * this program; if not, write to the Free Software Foundation, Inc., 51
  * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
+ * For the BCH implementation:
+ *
  * Copyright © 2011 Parrot S.A.
  *
  * Author: Ivan Djelic <ivan.dje...@parrot.com>
  *
- * Description:
- *
- * This library provides runtime configurable encoding/decoding of binary
- * Bose-Chaudhuri-Hocquenghem (BCH) codes.
- *
- * Call init_bch to get a pointer to a newly allocated bch_control structure 
for
- * the given m (Galois field order), t (error correction capability) and
- * (optional) primitive polynomial parameters.
- *
- * Call encode_bch to compute and store ecc parity bytes to a given buffer.
- * Call decode_bch to detect and locate errors in received data.
- *
- * On systems supporting hw BCH features, intermediate results may be provided
- * to decode_bch in order to skip certain steps. See decode_bch() documentation
- * for details.
- *
- * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
- * parameters m and t; thus allowing extra compiler optimizations and providing
- * better (up to 2x) encoding performance. Using this option makes sense when
- * (m,t) are fixed and known in advance, e.g. when using BCH error correction
- * on a particular NAND flash device.
- *
- * Algorithmic details:
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
  *
- * Encoding is performed by processing 32 input bits in parallel, using 4
- * remainder lookup tables.
+ * For the randomizer and image builder implementation:
  *
- * The final stage of decoding involves the following internal steps:
- * a. Syndrome computation
- * b. Error locator polynomial computation using Berlekamp-Massey algorithm
- * c. Error locator root finding (by far the most expensive step)
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
  *
- * In this implementation, step c is not performed using the usual Chien 
search.
- * Instead, an alternative approach described in [1] is used. It consists in
- * factoring the error locator polynomial using the Berlekamp Trace algorithm
- * (BTA) down to a certain degree (4), after which ad hoc low-degree polynomial
- * solving techniques [2] are used. The resulting algorithm, called BTZ, yields
- * much better performance than Chien search for usual (m,t) values (typically
- * m >= 13, t < 32, see [1]).
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
  *
- * [1] B. Biswas, V. Herbert. Efficient root finding of polynomials over fields
- * of characteristic 2, in: Western European Workshop on Research in Cryptology
- * - WEWoRC 2009, Graz, Austria, LNCS, Springer, July 2009, to appear.
- * [2] [Zin96] V.A. Zinoviev. On the solution of equations of degree 10 over
- * finite fields GF(2^q). In Rapport de recherche INRIA no 2829, 1996.
  */
 
 #include 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v3 2/4] nand-image-builder: Add error messages to check_image_info()

2016-06-03 Thread Boris Brezillon
Add error messages explaining what is wrong or missing in the arguments
passed by to the sunxi-nand-image-builder tool.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortm...@web.de>
---
Changes since v1:
- Drop uneeded braces
---
 nand-image-builder.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index a5fb3d8..465ab36 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -941,20 +941,37 @@ static int check_image_info(struct image_info *info)
int eccbytes, eccsteps;
unsigned i;
 
-   if (!info->page_size || !info->oob_size || !info->eraseblock_size ||
-   !info->usable_page_size)
+   if (!info->page_size) {
+   fprintf(stderr, "--page-size is missing\n");
return -EINVAL;
+   }
+
+   if (!info->page_size) {
+   fprintf(stderr, "--oob-size is missing\n");
+   return -EINVAL;
+   }
+
+   if (!info->eraseblock_size) {
+   fprintf(stderr, "--eraseblock-size is missing\n");
+   return -EINVAL;
+   }
 
-   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024)
+   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024) {
+   fprintf(stderr, "Invalid ECC step argument: %d\n",
+   info->ecc_step_size);
return -EINVAL;
+   }
 
for (i = 0; i < ARRAY_SIZE(valid_ecc_strengths); i++) {
if (valid_ecc_strengths[i] == info->ecc_strength)
break;
}
 
-   if (i == ARRAY_SIZE(valid_ecc_strengths))
+   if (i == ARRAY_SIZE(valid_ecc_strengths)) {
+   fprintf(stderr, "Invalid ECC strength argument: %d\n",
+   info->ecc_strength);
return -EINVAL;
+   }
 
eccbytes = DIV_ROUND_UP(info->ecc_strength * 14, 8);
if (eccbytes % 2)
@@ -964,8 +981,11 @@ static int check_image_info(struct image_info *info)
eccsteps = info->usable_page_size / info->ecc_step_size;
 
if (info->page_size + info->oob_size <
-   info->usable_page_size + (eccsteps * (eccbytes)))
+   info->usable_page_size + (eccsteps * eccbytes)) {
+   fprintf(stderr,
+   "ECC bytes do not fit in the NAND page, choose a weaker 
ECC\n");
return -EINVAL;
+   }
 
return 0;
 }
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v3 3/4] nand-image-builder: Rework the help context

2016-06-03 Thread Boris Brezillon
Add explanations on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Changes since v2:
- limit line width in the help context

Changes since v1:
- use shorter option names
- rework the help context
---
 nand-image-builder.c | 70 +---
 1 file changed, 50 insertions(+), 20 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 465ab36..230ed0c 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -917,21 +917,51 @@ static void display_help(int status)
 {
fprintf(status == EXIT_SUCCESS ? stdout : stderr,
"Usage: sunxi-nand-image-builder [OPTIONS] source-image 
output-image\n"
+   "\n"
"Creates a raw NAND image that can be read by the sunxi NAND 
controller.\n"
"\n"
-   "-h --help  Display 
this help and exit\n"
-   "-c /   --ecc=/ ECC 
config\n"
-   "   Valid 
strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
-   "   Valid 
steps: 512 and 1024\n"
-   "-p   --page-size=  Page 
size\n"
-   "-o   --oob-size=   OOB 
size\n"
-   "-u   --usable-page-size=   Usable 
page size. Only needed for boot0 mode\n"
-   "-e   --eraseblock-size=Erase 
block size\n"
-   "-b --boot0 Build a 
boot0 image.\n"
-   "-s --scramble  
Scramble data\n"
-   "-a --address   Where 
the image will be programmed.\n"
-   "   This 
option is only required for non boot0 images that are meant to be programmed at 
a non eraseblock aligned offset.\n"
-   "\n");
+   "-h   --help   Display this help and 
exit\n"
+   "-c /  --ecc=/   ECC config 
(strength/step-size)\n"
+   "-p --page=Page size\n"
+   "-o --oob= OOB size\n"
+   "-u --usable=  Usable page size\n"
+   "-e --eraseblock=  Erase block size\n"
+   "-b   --boot0  Build a boot0 image.\n"
+   "-s   --scramble   Scramble data\n"
+   "-a   --addressWhere the image will be 
programmed.\n"
+   "\n"
+   "Notes:\n"
+   "All the information you need to pass to this tool should be 
part of\n"
+   "the NAND datasheet.\n"
+   "\n"
+   "The NAND controller only supports the following ECC configs\n"
+   "  Valid ECC strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
+   "  Valid ECC step size: 512 and 1024\n"
+   "\n"
+   "If you are building a boot0 image, you'll have specify extra 
options.\n"
+   "These options should be chosen based on the layouts described 
here:\n"
+   " http://linux-sunxi.org/NAND#More_information_on_BROM_NAND\n;
+   "\n"
+   "  --usable should be assigned the 'Hardware page' value\n"
+   "  --ecc should be assigned the 'ECC capacity'/'ECC page' 
values\n"
+   "  --usable should be smaller than --page\n"
+   "\n"
+   "The --address option is only required for non-boot0 images 
that are \n"
+   "meant to be programmed at a non eraseblock aligned offset.\n"
+   "\n"
+   "Examples:\n"
+   "  The H27UCG8T2BTR-BC NAND exposes\n"
+   "  * 16k pages\n"
+   "  * 1280 OOB bytes per page\n"
+   "  * 4M eraseblocks\n"
+   "  * requires data scrambling\n"
+   "  * expects a minimum ECC of 40bits/1024bytes\n"
+   "\n"
+   "  A normal image can be generated with\n"
+   "sunxi-nand-image-builder -p 16384 -o 1280 

[linux-sunxi] [PATCH sunxi-tools v3 4/4] nand-image-builder: Fix --help/-h option

2016-06-03 Thread Boris Brezillon
--help/-h is not working correctly (it's printing the help context on
stderr instead of stdout).
Adding a valid shortcut for --help solves the problem.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 nand-image-builder.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 230ed0c..cb39d5d 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -1032,7 +1032,7 @@ int main(int argc, char **argv)
int option_index = 0;
char *endptr = NULL;
static const struct option long_options[] = {
-   {"help", no_argument, 0, 0},
+   {"help", no_argument, 0, 'h'},
{"ecc", required_argument, 0, 'c'},
{"page", required_argument, 0, 'p'},
{"oob", required_argument, 0, 'o'},
@@ -1044,7 +1044,7 @@ int main(int argc, char **argv)
{0, 0, 0, 0},
};
 
-   int c = getopt_long(argc, argv, "c:p:o:u:e:ba:s",
+   int c = getopt_long(argc, argv, "c:p:o:u:e:ba:sh",
long_options, _index);
if (c == EOF)
break;
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools v2 3/3] nand-image-builder: Rework the help context

2016-06-02 Thread Boris Brezillon
Add explanations on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Changes since v1:
- use shorter option names
- rework the help context
---
 nand-image-builder.c | 67 
 1 file changed, 47 insertions(+), 20 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 465ab36..98c0a82 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -917,21 +917,48 @@ static void display_help(int status)
 {
fprintf(status == EXIT_SUCCESS ? stdout : stderr,
"Usage: sunxi-nand-image-builder [OPTIONS] source-image 
output-image\n"
+   "\n"
"Creates a raw NAND image that can be read by the sunxi NAND 
controller.\n"
"\n"
-   "-h --help  Display 
this help and exit\n"
-   "-c /   --ecc=/ ECC 
config\n"
-   "   Valid 
strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
-   "   Valid 
steps: 512 and 1024\n"
-   "-p   --page-size=  Page 
size\n"
-   "-o   --oob-size=   OOB 
size\n"
-   "-u   --usable-page-size=   Usable 
page size. Only needed for boot0 mode\n"
-   "-e   --eraseblock-size=Erase 
block size\n"
-   "-b --boot0 Build a 
boot0 image.\n"
-   "-s --scramble  
Scramble data\n"
-   "-a --address   Where 
the image will be programmed.\n"
-   "   This 
option is only required for non boot0 images that are meant to be programmed at 
a non eraseblock aligned offset.\n"
-   "\n");
+   " -h--help  Display this 
help and exit\n"
+   " -c /  --ecc=/ ECC config\n"
+   "   Valid 
strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
+   "   Valid steps: 
512 and 1024\n"
+   " -p  --page=   Page size\n"
+   " -o  --oob=OOB size\n"
+   " -u  --usable= Usable page 
size. Only needed for boot0 mode\n"
+   " -e  --eraseblock= Erase block 
size\n"
+   " -b--boot0 Build a boot0 
image.\n"
+   " -s--scramble  Scramble data\n"
+   " -a--address   Where the image 
will be programmed.\n"
+   "\n"
+   "Notes:\n"
+   " All the information you need to pass to this tool should be 
part of the NAND datasheet.\n"
+   "\n"
+   " If you are building a boot0 image, you'll have specify extra 
options.\n"
+   " These options should be chosen based on the layouts described 
here:\n"
+   "  http://linux-sunxi.org/NAND#More_information_on_BROM_NAND\n;
+   "\n"
+   "   --usable should be assigned the 'Hardware page' value\n"
+   "   --ecc should be assigned the 'ECC capacity'/'ECC page' 
values\n"
+   "   --usable should be smaller than --page\n"
+   "\n"
+   " The --address option is only required for non-boot0 images 
that are meant to be\n"
+   " programmed at a non eraseblock aligned offset.\n"
+   "\n"
+   "Examples:\n"
+   " The H27UCG8T2BTR-BC NAND exposes\n"
+   "  * 16k pages\n"
+   "  * 1280 OOB bytes per page\n"
+   "  * 4M eraseblocks\n"
+   "  * requires data scrambling\n"
+   "  * expects a minimum ECC of 40bits/1024bytes\n"
+   "\n"
+   " A boot0 image can be generated with the following command\n"
+   "   sunxi-nand-image-builder -p 16384

[linux-sunxi] [PATCH sunxi-tools v2 1/3] nand-image-builder: Fix the copyright header

2016-06-02 Thread Boris Brezillon
Add NextThing Co. and Free Electrons copyrights and add myself as the
author of the randomizer and image builder implementation.

Remove the lengthy description explaining how the BCH implementation works,
since this is the purpose of this tool is not to expose a BCH library
(which was the case of the original source code I copied from the kernel).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Changes since v1:
- Add a link to the original bch.c source file
---
 nand-image-builder.c | 49 -
 1 file changed, 8 insertions(+), 41 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 645d1cc..a5fb3d8 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -14,55 +14,22 @@
  * this program; if not, write to the Free Software Foundation, Inc., 51
  * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
+ * For the BCH implementation:
+ *
  * Copyright © 2011 Parrot S.A.
  *
  * Author: Ivan Djelic <ivan.dje...@parrot.com>
  *
- * Description:
- *
- * This library provides runtime configurable encoding/decoding of binary
- * Bose-Chaudhuri-Hocquenghem (BCH) codes.
- *
- * Call init_bch to get a pointer to a newly allocated bch_control structure 
for
- * the given m (Galois field order), t (error correction capability) and
- * (optional) primitive polynomial parameters.
- *
- * Call encode_bch to compute and store ecc parity bytes to a given buffer.
- * Call decode_bch to detect and locate errors in received data.
- *
- * On systems supporting hw BCH features, intermediate results may be provided
- * to decode_bch in order to skip certain steps. See decode_bch() documentation
- * for details.
- *
- * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
- * parameters m and t; thus allowing extra compiler optimizations and providing
- * better (up to 2x) encoding performance. Using this option makes sense when
- * (m,t) are fixed and known in advance, e.g. when using BCH error correction
- * on a particular NAND flash device.
- *
- * Algorithmic details:
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
  *
- * Encoding is performed by processing 32 input bits in parallel, using 4
- * remainder lookup tables.
+ * For the randomizer and image builder implementation:
  *
- * The final stage of decoding involves the following internal steps:
- * a. Syndrome computation
- * b. Error locator polynomial computation using Berlekamp-Massey algorithm
- * c. Error locator root finding (by far the most expensive step)
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
  *
- * In this implementation, step c is not performed using the usual Chien 
search.
- * Instead, an alternative approach described in [1] is used. It consists in
- * factoring the error locator polynomial using the Berlekamp Trace algorithm
- * (BTA) down to a certain degree (4), after which ad hoc low-degree polynomial
- * solving techniques [2] are used. The resulting algorithm, called BTZ, yields
- * much better performance than Chien search for usual (m,t) values (typically
- * m >= 13, t < 32, see [1]).
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
  *
- * [1] B. Biswas, V. Herbert. Efficient root finding of polynomials over fields
- * of characteristic 2, in: Western European Workshop on Research in Cryptology
- * - WEWoRC 2009, Graz, Austria, LNCS, Springer, July 2009, to appear.
- * [2] [Zin96] V.A. Zinoviev. On the solution of equations of degree 10 over
- * finite fields GF(2^q). In Rapport de recherche INRIA no 2829, 1996.
  */
 
 #include 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-06-01 Thread Boris Brezillon
On Wed, 1 Jun 2016 15:35:07 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:

> On Wed,  1 Jun 2016 13:23:24 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > NAND chips are supposed to expose their capabilities through advanced
> > mechanisms like READID, ONFI or JEDEC parameter tables. While those
> > methods are appropriate for the bootloader itself, it's way to
> > complicated and takes too much space to fit in the SPL.
> > 
> > Replace those mechanisms by a dumb 'trial and error' mechanism.
> > 
> > With this new approach we can get rid of the fixed config list that was
> > used in the sunxi NAND SPL driver.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > Acked-by: Hans de Goede <hdego...@redhat.com>  
> 
> We can also have these NAND parameters stored in the SPL header and
> added there by a NAND image builder tool. This may save some precious
> space in the SPL and also improve the reliability of detection.
> 
> Yes, this brings the necessity of the image builder tool into the
> spotlight (something that converts the "u-boot-sunxi-with-spl.bin"
> to a NAND image) but this has always been a problem. We have some
> ongoing discussion about this in the linux-sunxi mailing list:
> https://groups.google.com/forum/#!topic/linux-sunxi/HsWRG-nuV-w
> 
> It also makes a lot of sense to have the NAND support functionality
> enabled in the SPL for all sunxi boards by default, so the code size
> does matter. We still do have the runtime decompression opportunity
> as the strategic reserve [1], which should provide additional 4 or
> 5 KiB of space for the code. Still we need to be very careful about
> using up this reserve, to ensure that it is well spent on something
> useful (such as NAND support) instead of being just wasted by the
> bloatware cultists :-)

Oh, come one! I just did the test, and we save 352 bytes when dropping
the auto-detection code. Do we really want to delay the NAND support
just because you want the perfect solution (which as I already said,
will not be trivial to implement).

I'm not telling that your approach is wrong, just that it's not a
priority right now, so let's move on and improve it iteratively.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH sunxi-tools 3/3] nand-image-builder: Add more details in the help context

2016-06-01 Thread Boris Brezillon
On Wed, 1 Jun 2016 14:43:22 +0200
Bernhard Nortmann <bernhard.nortm...@web.de> wrote:

> Am 01.06.2016 um 11:05 schrieb Boris Brezillon:
> > Add explanation on where the options to pass to the tool should be
> > extracted from, and add two examples to illustrate this explanation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > ---
> >   nand-image-builder.c | 17 +++--
> >   1 file changed, 15 insertions(+), 2 deletions(-)  
> 
> I dislike the rather long line lengths involved with the descriptions / 
> usage
> help here. Unfortunately I don't have an immediate idea of how to cut 
> down on
> those.
> 
> Also some options seem a bit lengthy / overly verbose? Personally, I'd trim
> them - e.g. "--page-size=" -> "--page=", 
> "--usable-page-size="
> --> "--usable=", "--eraseblock-size=" -> "--erase=" etc.,  
> as long a there's no ambiguity.

Okay.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-06-01 Thread Boris Brezillon
On Wed, 1 Jun 2016 14:41:36 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:

> On Mon, 30 May 2016 19:02:13 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > On Mon, 30 May 2016 19:46:17 +0300
> > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> >   
> > > On Mon, 30 May 2016 17:24:16 +0200
> > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > 
> > > > Hi Hans,
> > > > 
> > > > On Mon, 30 May 2016 17:12:53 +0200
> > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > >   
> > > > > Generating raw NAND images is particularly useful for boot0 images
> > > > > creation since the mainline driver is not supporting the funky layout
> > > > > used by Allwinner's ROM code to load the boot0 binary from NAND.
> > > > > 
> > > > > This tools also allows one to generate raw images for 'normal' 
> > > > > partitions
> > > > > so that they can be flashed before soldering on the NAND on the board
> > > > > (using a regular NAND programmer).
> > > > > 
> > > > > The tool takes care of generating ECC bytes and randomizing data as
> > > > > expected by the NAND controller, and re-arranging the ECC/data 
> > > > > sections
> > > > > correctly.
> > > > 
> > > > Don't know how you want to proceed regarding NAND SPL image creation in
> > > > u-boot. We could either copy the sunxi-nand-image-builder sources in
> > > > u-boot or provide a macro to pass the sunxi-tools binaries path
> > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools
> > > > installed on his build platform.
> > > > 
> > > > Note that we'll need extra padding/concatenation steps to build an SPL
> > > > image suitable for MLC NANDs.  
> > > 
> > > Hi,
> > > 
> > > I guess, it is not a big secret that I'm also working on the SPI flash
> > > boot support at the moment. And some information about the progress is
> > > available here:
> > > 
> > > https://linux-sunxi.org/Bootable_SPI_flash
> > > 
> > > IMHO one of the most important requirements is to ensure that the device
> > > can be always unbricked by the end users in a very simple way. That's
> > > why I have added the SPI flash programming feature to the sunxi-fel
> > > tool and it is available in a wip branch since about a week ago:
> > > 
> > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip
> > > 
> > > There is still some work left to do. For example, just having SPI
> > > flash read/write functionality (which already works btw) is not
> > > good enough because it is not sufficiently foolproof. There will
> > > be a dedicated high level "spiflash-program" commmand to flash
> > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot.
> > > We had discussed this a bit on the IRC earlier:
> > > 
> > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894;
> > > 
> > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin
> > > image to automatically add some redundancy (two copies of the SPL):
> > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations
> > > And also pass some information about the SPI flash type via the SPL
> > > header (for example, the single/dual SPI mode, the maximum SPI clock
> > > speed, etc.). So that the SPL can use this information directly
> > > without any need to have extra code bloat responsible for doing
> > > runtime discovery of all these parameters.
> > > 
> > > But the most important foolproof feature would be of course a warning
> > > "You are trying to flash a firmware for an incompatible board, are
> > > you really sure?" :-) Later we can also have digital signatures
> > > verification built into the sunxi-fel, and other nice things.
> > > 
> > > 
> > > Boris, I think that your NAND use case is not very much different in
> > > principle. You can't expect the users to desolder the NAND chip and
> > > use an external NAND programmer tool when they need to unbrick their
> > > device, right?
> > > 
> > 
> > That's absolutely not the goal of this tool. It's just here to generate
> > raw 

[linux-sunxi] [PATCH v2 5/7] spl: nand: sunxi: rework status polling loop

2016-06-01 Thread Boris Brezillon
check_value_xxx() helpers are using a 1ms delay between each test, which
can be quite long for some operations (like a page read on an SLC NAND).
Since we don't have anything to do but to poll this register, reduce the
delay between each test to 1us.

While we're at it, rename the max_number_of_retries parameters and the
MAX_RETRIES macro into timeout_us and DEFAULT_TIMEOUT_US to reflect that
we're actually waiting a given amount of time and not only a number of
retries.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 13e6eab..55b3c8a 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,35 +119,31 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-#define MAX_RETRIES 10
+#define DEFAULT_TIMEOUT_US 10
 
 static int check_value_inner(int offset, int expected_bits,
-   int max_number_of_retries, int negation)
+int timeout_us, int negation)
 {
-   int retries = 0;
do {
int val = readl(offset) & expected_bits;
if (negation ? !val : val)
return 1;
-   mdelay(1);
-   retries++;
-   } while (retries < max_number_of_retries);
+   udelay(1);
+   } while (--timeout_us);
 
return 0;
 }
 
 static inline int check_value(int offset, int expected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, expected_bits,
-   max_number_of_retries, 0);
+   return check_value_inner(offset, expected_bits, timeout_us, 0);
 }
 
 static inline int check_value_negated(int offset, int unexpected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, unexpected_bits,
-   max_number_of_retries, 1);
+   return check_value_inner(offset, unexpected_bits, timeout_us, 1);
 }
 
 void nand_init(void)
@@ -162,7 +158,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CTL);
 
if (!check_value_negated(SUNXI_NFC_BASE + NFC_CTL,
-NFC_CTL_RESET, MAX_RETRIES)) {
+NFC_CTL_RESET, DEFAULT_TIMEOUT_US)) {
printf("Couldn't initialize nand\n");
}
 
@@ -172,7 +168,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error timeout waiting for nand reset\n");
return;
}
@@ -260,14 +256,15 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error while initializing dma interrupt\n");
return -1;
}
writel(NFC_ST_DMA_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
-SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
+SUNXI_DMA_DDMA_CFG_REG_LOADING,
+DEFAULT_TIMEOUT_US)) {
printf("Error while waiting for dma transfer to finish\n");
return -1;
}
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 1/7] spl: nand: sunxi: remove support for so-called 'syndrome' mode

2016-06-01 Thread Boris Brezillon
The sunxi SPL NAND controller driver supports use 'BootROM'-like configs,
that is, configs where the ECC bytes and real data are interleaved in the
page instead of putting ECC bytes in the OOB area.

Doing that has several drawbacks:
- since you're interleaving data and ECC bytes you can't use the whole page
  otherwise you might override the bad block marker with non-FF bytes.
- to solve the bad block marker problem, the ROM code supports partially
  using the page, but this introduces a huge penalty both in term of read
  speed and NAND memory usage. While this is fine for rather small
  binaries(like the SPL one which is at maximum 24KB large), it becomes
  non-negligible for the bootloader image (several hundred of KB).
- auto-detection of the page size is not reliable (this is in my opinion
  the biggest problem). If you get the page size wrong, you'll end up
  reading data at a different offset than what was specified by the caller
  and the reading may succeed (if valid data were written at this address).

For all those reasons I think it's wiser to completely remove support for
'syndrome' configs. If we ever need to support it again, then I'd recommend
specifying all the config parameters through Kconfig options.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 56 ++-
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b0e07aa..1739da2 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,9 +119,6 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-/* random seed used for syndrome calls */
-const uint16_t random_seed_syndrome = 0x4a80;
-
 #define MAX_RETRIES 10
 
 static int check_value_inner(int offset, int expected_bits,
@@ -183,7 +180,7 @@ void nand_init(void)
 }
 
 static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -209,17 +206,11 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
page = real_addr / page_size;
column = real_addr % page_size;
 
-   if (syndrome)
-   column += (column / ecc_page_size) * ecc_off;
-
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   if (syndrome)
-   rand_seed = random_seed_syndrome;
-   else
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % 128];
 
writel((rand_seed << 16) | NFC_ECC_RANDOM_EN | NFC_ECC_EN
| NFC_ECC_PIPELINE | (ecc_mode << 12),
@@ -228,9 +219,8 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome)
-   writel(page_size + (column / ecc_page_size) * ecc_off,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
@@ -266,7 +256,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
NFC_PAGE_CMD | NFC_WAIT_FLAG |
((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
-   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
+   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
@@ -292,7 +282,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
 }
 
 static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest, int syndrome)
+   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
 {
void *end = dest + size;
 
@@ -301,16 +291,14 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 
for ( ;dest < end; dest += ecc_page_size, offs += ecc_page_size) {
if (nand_read_page(page_size, ecc_strength, ecc_page_size,
-  addr_cycles, offs, (dma_addr_t)dest,
-  syndrome))
+  addr_cycles, offs, (dma_addr_t)dest))
return -1;
}
 
return 0;

[linux-sunxi] [PATCH v2 4/7] spl: nand: sunxi: stop guessing the redundant u-boot offset

2016-06-01 Thread Boris Brezillon
Use CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND value instead of trying to guess
where the redundant u-boot image is based on simple (and most of the time
erroneous) heuristics.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 85cb127..13e6eab 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -344,26 +344,6 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest)
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
-   /*
-* u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
-* for backup u-boot 1 erase block further.
-*/
-   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
-   const uint32_t boot_offsets[] = {
-   CONFIG_SPL_NAND_U_BOOT_OFFS,
-   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
-   };
-   int i;
-
-   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
-   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
-   if (nand_read_buffer(boot_offsets[i], size,
-dest) == 0)
-   return 0;
-   }
-   return -1;
-   }
-
return nand_read_buffer(offs, size, dest);
 }
 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-06-01 Thread Boris Brezillon
NAND chips are supposed to expose their capabilities through advanced
mechanisms like READID, ONFI or JEDEC parameter tables. While those
methods are appropriate for the bootloader itself, it's way to
complicated and takes too much space to fit in the SPL.

Replace those mechanisms by a dumb 'trial and error' mechanism.

With this new approach we can get rid of the fixed config list that was
used in the sunxi NAND SPL driver.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
Changes since v1:
- fix the nand_max_ecc_strength()
---
 drivers/mtd/nand/sunxi_nand_spl.c | 262 +-
 1 file changed, 204 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b43f2af..1ef7366 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -103,6 +103,7 @@ struct nfc_config {
int addr_cycles;
int nseeds;
bool randomize;
+   bool valid;
 };
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
@@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
u32 offs)
return 0;
 }
 
+static int nand_reset_column(void)
+{
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
+  (1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static int nand_read_page(const struct nfc_config *conf, u32 offs,
  void *dest, int len)
 {
@@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config *conf, 
u32 offs,
return (val & 0x1) ? 1 : 0;
 }
 
-static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
+static int nand_max_ecc_strength(struct nfc_config *conf)
 {
-   void *end = dest + size;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
-   struct nfc_config conf = {
-   .page_size = page_size,
-   .ecc_size = ecc_page_size,
-   .addr_cycles = addr_cycles,
-   .nseeds = ARRAY_SIZE(random_seed),
-   .randomize = true,
-   };
+   static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
};
+   int max_oobsize, max_ecc_bytes;
+   int nsectors = conf->page_size / conf->ecc_size;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   conf.ecc_strength = i;
+   /*
+* ECC strength is limited by the size of the OOB area which is
+* correlated with the page size.
+*/
+   switch (conf->page_size) {
+   case 2048:
+   max_oobsize = 64;
+   break;
+   case 4096:
+   max_oobsize = 256;
+   break;
+   case 8192:
+   max_oobsize = 640;
+   break;
+   case 16384:
+   max_oobsize = 1664;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   max_ecc_bytes = max_oobsize / nsectors;
+
+   for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
+   if (ecc_bytes[i] > max_ecc_bytes)
break;
-   }
}
 
+   if (!i)
+   return -EINVAL;
 
-   nand_apply_config();
+   return i - 1;
+}
 
-   for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
-   if (nand_load_page(, offs))
-   return -1;
+static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
+ void *dest)
+{
+   /* NAND with pages > 4k will likely require 1k sector size. */
+   int min_ecc_size = conf->page_size > 4096 ? 1024 : 512;
+   int page = offs / conf->page_size;
+   int ret;
 
-   if (nand_read_page(, offs, dest, page_size))
-   return -1;
+   /*
+* In most cases, 1k sectors are preferred over 512b ones, start
+* testing this config first.
+*/
+   for (conf->ecc_size = 1024; conf->ecc_size >= min_ecc_size;
+conf->ecc_size >>= 1) {
+   int max_ecc_strength = nan

[linux-sunxi] [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

2016-06-01 Thread Boris Brezillon
The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
to explicitly depend on platforms that are not already defining it in their
include/configs/.h header.

Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency
on NAND_SUNXI and make it dependent on SPL selection.

common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to
CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay
compatible with the existing behavior.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 common/spl/spl_nand.c | 4 
 drivers/mtd/nand/Kconfig  | 9 +
 drivers/mtd/nand/sunxi_nand_spl.c | 8 
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index bbd9546..612bd4a 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -10,6 +10,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#endif
+
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
 int spl_nand_load_image(void)
 {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2fc73ef..4b0f92c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -99,16 +99,17 @@ config SYS_NAND_BUSWIDTH_16BIT
not available while configuring controller. So a static 
CONFIG_NAND_xx
is needed to know the device's bus-width in advance.
 
-# Enhance depends when converting drivers to Kconfig which use this config
-config SYS_NAND_U_BOOT_OFFS
+if SPL
+
+# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS.
+# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined.
+config SPL_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
-   depends on NAND_SUNXI
help
Set the offset from the start of the nand where u-boot should be
loaded from.
 
-if SPL
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 1739da2..85cb127 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -348,14 +348,14 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
 * u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
 * for backup u-boot 1 erase block further.
 */
-   const uint32_t eraseblock_size = CONFIG_SYS_NAND_U_BOOT_OFFS / 2;
+   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
const uint32_t boot_offsets[] = {
-   CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_U_BOOT_OFFS + eraseblock_size,
+   CONFIG_SPL_NAND_U_BOOT_OFFS,
+   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
};
int i;
 
-   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
+   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
if (nand_read_buffer(boot_offsets[i], size,
 dest) == 0)
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 3/7] spl: nand: support redundant u-boot image

2016-06-01 Thread Boris Brezillon
On modern NAND it's more than recommended to have a backup copy of the
u-boot binary to recover from corruption: bitflips are quite common on
MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
more quickly than what you would see on an SLC NAND.

Add an extra Kconfig option to specify the offset of the redundant u-boot
image.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 common/spl/spl_nand.c| 8 
 drivers/mtd/nand/Kconfig | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 612bd4a..0bf0848 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -12,6 +12,9 @@
 
 #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
 #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND
+#else
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
 #endif
 
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
@@ -111,6 +114,11 @@ int spl_nand_load_image(void)
 #endif
/* Load u-boot */
err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
+#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
+   if (err)
+   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
+   header);
+#endif
nand_deselect();
return err;
 }
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4b0f92c..2f1d1f7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -110,6 +110,12 @@ config SPL_NAND_U_BOOT_OFFS
Set the offset from the start of the nand where u-boot should be
loaded from.
 
+config SPL_NAND_U_BOOT_OFFS_REDUND
+   hex "Location in NAND to read U-Boot from"
+   default SPL_NAND_U_BOOT_OFFS
+   help
+   Set the offset from the start of the nand where u-boot should be
+   loaded from.
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v2 6/7] spl: nand: sunxi: split 'load page' and 'read page' logic

2016-06-01 Thread Boris Brezillon
Split the 'load page' and 'read page' logic in 2 different functions so
we can later load the page and test different ECC configs without the
penalty of reloading the same page in the NAND cache.

We also move common setup to a dedicated function (nand_apply_config()) to
avoid rewriting the same values in NFC registers each time we read a page.

These new functions are passed a pointer to an nfc_config struct to limit
the number of parameters.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 185 +++---
 1 file changed, 114 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 55b3c8a..b43f2af 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -66,6 +66,8 @@
 #define NFC_ROW_AUTO_INC   (1 << 27)
 #define NFC_SEND_CMD3  (1 << 28)
 #define NFC_SEND_CMD4  (1 << 29)
+#define NFC_RAW_CMD(0 << 30)
+#define NFC_PAGE_CMD   (2 << 30)
 
 #define NFC_ST_CMD_INT_FLAG(1 << 1)
 #define NFC_ST_DMA_INT_FLAG(1 << 2)
@@ -78,9 +80,6 @@
 #define NFC_CMD_RNDOUT 0x05
 #define NFC_CMD_READSTART  0x30
 
-
-#define NFC_PAGE_CMD   (2 << 30)
-
 #define SUNXI_DMA_CFG_REG0  0x300
 #define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
 #define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
@@ -97,6 +96,15 @@
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
 
+struct nfc_config {
+   int page_size;
+   int ecc_strength;
+   int ecc_size;
+   int addr_cycles;
+   int nseeds;
+   bool randomize;
+};
+
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
 /* random seed used by linux */
@@ -175,50 +183,70 @@ void nand_init(void)
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 }
 
-static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
+static void nand_apply_config(const struct nfc_config *conf)
 {
-   uint32_t val;
-   int i, ecc_off = 0;
-   uint16_t ecc_mode = 0;
-   uint16_t rand_seed;
-   uint32_t page;
-   uint16_t column;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+   u32 val;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   ecc_mode = i;
-   break;
-   }
+   val = readl(SUNXI_NFC_BASE + NFC_CTL);
+   val &= ~NFC_CTL_PAGE_SIZE_MASK;
+   writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
+  SUNXI_NFC_BASE + NFC_CTL);
+   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
+   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
+}
+
+static int nand_load_page(const struct nfc_config *conf, u32 offs)
+{
+   int page = offs / conf->page_size;
+
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(((page & 0x) << 16), SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
+   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
+  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -EIO;
}
 
-   /* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
-   /* HW ECC always work with even numbers of ECC bytes */
-   ecc_off += (ecc_off & 1);
-   ecc_off += 4; /* prepad */
+   return 0;
+}
+
+static int nand_read_page(const struct nfc_config *conf, u32 offs,
+ void *dest, int len)
+{
+   dma_addr_t dst = (dma_addr_t)dest;
+   int nsectors = len / conf->ecc_size;
+   u16 rand_seed;
+   u32 val;
+   int page;
+
+   page = offs / conf->page_size;
 
-   page = real_addr / page_size;
-   column = real_addr % page_size;
+   if (offs % conf->page_size || len % conf->ecc_size ||
+   len > conf->page_size || len < 0)
+   

[linux-sunxi] [PATCH v2 0/7] spl: nand: sunxi: implement auto-detection

2016-06-01 Thread Boris Brezillon
Hello,

This patch series aims at adding support for NAND auto-detection to
the sunxi SPL NAND driver.

As explained in patch 7, this auto-detection is nothing more than a
dumb "trial and error" logic, but it allows one to use the same
SPL binary for all kind of sunxi boards booting from NAND.
Of course, this approach might increase a bit the boot-time, but this
is something we could address by adding a "default NAND config",
that would be tested before launching the auto-detection procedure.

Now let's detail a bit what's inside this patch-set.
Patch 1 is a cleanup removing support for BootROM configs, which in
my opinion are not only inefficient but also not reliable (at least
the current implementation does not guarantee that you'll be using
the correct configuration when reading the NAND).

Piotr, Hans, any comment?
Is this a real problem if we get rid of syndrome/BootROM configs?
I mean, are you really using this mode? If that's not the case, I'd
prefer dropping support for this feature. ITOH, if you really
need this mode, then I'd recommend adding Kconfig options to specify
the exact config to be used rather than randomly testing configs
(see my explanation in patch 1).

Patch 2 is renaming the SYS_NAND_U_BOOT_OFFS Kconfig option to make it
usable on all platforms (not only sunxi) and avoid conflicts when
one board is defining CONFIG_SYS_NAND_U_BOOT_OFFS in its
include/configs/.h header.

Patch 3 is adding generic support for redundant u-boot images, which
is particularly useful on modern NANDs where corruptions is likely to
happen.
Patch 4 is just getting rid of the open-coded version of redundant
u-boot image support in the sunxi NAND driver.

Patch 5 is a simple improvement of the NAND controller status polling
loop, which is really important to make the "trial and error"
approach efficient (we try to limit the impact on boot-time here).
Patch 6 and 7 are implementing the auto-detection logic.

Best Regards,

Boris

Changes since v1:
- added Hans ack
- fixed 2 typos in patch 7

Boris Brezillon (7):
  spl: nand: sunxi: remove support for so-called 'syndrome' mode
  spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
  spl: nand: support redundant u-boot image
  spl: nand: sunxi: stop guessing the redundant u-boot offset
  spl: nand: sunxi: rework status polling loop
  spl: nand: sunxi: split 'load page' and 'read page' logic
  spl: nand: sunxi: add support for NAND config auto-detection

 common/spl/spl_nand.c |  12 +
 drivers/mtd/nand/Kconfig  |  15 +-
 drivers/mtd/nand/sunxi_nand_spl.c | 480 --
 3 files changed, 332 insertions(+), 175 deletions(-)

-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-06-01 Thread Boris Brezillon
On Fri, 20 May 2016 15:55:51 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> NAND chips are supposed to expose their capabilities through advanced
> mechanisms like READID, ONFI or JEDEC parameter tables. While those
> methods are appropriate for the bootloader itself, it's way to
> complicated and takes too much space to fit in the SPL.
> 
> Replace those mechanisms by a dumb 'trial and error' mechanism.
> 
> With this new approach we can get rid of the fixed config list that was
> used in the sunxi NAND SPL driver.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
>  drivers/mtd/nand/sunxi_nand_spl.c | 262 
> +-
>  1 file changed, 204 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
> b/drivers/mtd/nand/sunxi_nand_spl.c
> index b43f2af..cc2e69b 100644
> --- a/drivers/mtd/nand/sunxi_nand_spl.c
> +++ b/drivers/mtd/nand/sunxi_nand_spl.c
> @@ -103,6 +103,7 @@ struct nfc_config {
>   int addr_cycles;
>   int nseeds;
>   bool randomize;
> + bool valid;
>  };
>  
>  /* minimal "boot0" style NAND support for Allwinner A20 */
> @@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
> u32 offs)
>   return 0;
>  }
>  
> +static int nand_reset_column(void)
> +{
> + writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> +(NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> +(NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
> +SUNXI_NFC_BASE + NFC_RCMD_SET);
> + writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
> + writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
> +(1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
> +SUNXI_NFC_BASE + NFC_CMD);
> +
> + if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> +  DEFAULT_TIMEOUT_US)) {
> + printf("Error while initializing dma interrupt\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
>  static int nand_read_page(const struct nfc_config *conf, u32 offs,
> void *dest, int len)
>  {
> @@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config 
> *conf, u32 offs,
>   return (val & 0x1) ? 1 : 0;
>  }
>  
> -static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
> - int addr_cycles, uint32_t offs, uint32_t size, void *dest)
> +static int nand_max_ecc_strength(struct nfc_config *conf)
>  {
> - void *end = dest + size;
> - static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
> - struct nfc_config conf = {
> - .page_size = page_size,
> - .ecc_size = ecc_page_size,
> - .addr_cycles = addr_cycles,
> - .nseeds = ARRAY_SIZE(random_seed),
> - .randomize = true,
> - };
> + static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
> };
> + int max_oobsize, max_ecc_bytes;
> + int nsectors = conf->page_size / conf->ecc_size;
>   int i;
>  
> - for (i = 0; i < ARRAY_SIZE(strengths); i++) {
> - if (ecc_strength == strengths[i]) {
> - conf.ecc_strength = i;
> + /*
> +  * ECC strength is limited by the size of the OOB area which is
> +  * correlated with the page size.
> +  */
> + switch (conf->page_size) {
> + case 2048:
> + max_oobsize = 64;
> + break;
> + case 4096:
> + max_oobsize = 256;
> + break;
> + case 8196:
> + max_oobsize = 620;

Should be

case 8192:
max_oobsize = 640;

I'll send a v2 fixing that.

> + break;
> + case 16384:
> + max_oobsize = 1664;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + max_ecc_bytes = max_oobsize / nsectors;
> +
> + for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
> + if (ecc_bytes[i] > max_ecc_bytes)
>   break;
> - }
>   }
>  
> + if (!i)
> + return -EINVAL;
>  
> - nand_apply_config();
> + return i - 1;
> +}
>  
> - for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
> - if (nand_load_page(, offs))
> - return -1;
> +static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
> +   void *dest)
> +{
> + /* NAND w

[linux-sunxi] [PATCH sunxi-tools 1/3] nand-image-builder: Fix the copyright header

2016-06-01 Thread Boris Brezillon
Add NextThing Co. and Free Electrons copyrights and add myself as the
author of the randomizer and image builder implementation.

Remove the lengthy description explaining how the BCH implementation works,
since this is the purpose of this tool is not to expose a BCH library
(which was the case of the original source code I copied from the kernel).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Hi,

A PR containing those 2 patches has been seent [1], but please review
the changes before merging the PR.

Thanks,

Boris

[1]https://github.com/linux-sunxi/sunxi-tools/pull/55

 nand-image-builder.c | 48 ++--
 1 file changed, 6 insertions(+), 42 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 645d1cc..34eee4f 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -14,55 +14,19 @@
  * this program; if not, write to the Free Software Foundation, Inc., 51
  * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
+ * For the BCH implementation:
+ *
  * Copyright © 2011 Parrot S.A.
  *
  * Author: Ivan Djelic <ivan.dje...@parrot.com>
  *
- * Description:
- *
- * This library provides runtime configurable encoding/decoding of binary
- * Bose-Chaudhuri-Hocquenghem (BCH) codes.
- *
- * Call init_bch to get a pointer to a newly allocated bch_control structure 
for
- * the given m (Galois field order), t (error correction capability) and
- * (optional) primitive polynomial parameters.
- *
- * Call encode_bch to compute and store ecc parity bytes to a given buffer.
- * Call decode_bch to detect and locate errors in received data.
- *
- * On systems supporting hw BCH features, intermediate results may be provided
- * to decode_bch in order to skip certain steps. See decode_bch() documentation
- * for details.
- *
- * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
- * parameters m and t; thus allowing extra compiler optimizations and providing
- * better (up to 2x) encoding performance. Using this option makes sense when
- * (m,t) are fixed and known in advance, e.g. when using BCH error correction
- * on a particular NAND flash device.
- *
- * Algorithmic details:
- *
- * Encoding is performed by processing 32 input bits in parallel, using 4
- * remainder lookup tables.
+ * For the randomizer and image builder implementation:
  *
- * The final stage of decoding involves the following internal steps:
- * a. Syndrome computation
- * b. Error locator polynomial computation using Berlekamp-Massey algorithm
- * c. Error locator root finding (by far the most expensive step)
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
  *
- * In this implementation, step c is not performed using the usual Chien 
search.
- * Instead, an alternative approach described in [1] is used. It consists in
- * factoring the error locator polynomial using the Berlekamp Trace algorithm
- * (BTA) down to a certain degree (4), after which ad hoc low-degree polynomial
- * solving techniques [2] are used. The resulting algorithm, called BTZ, yields
- * much better performance than Chien search for usual (m,t) values (typically
- * m >= 13, t < 32, see [1]).
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
  *
- * [1] B. Biswas, V. Herbert. Efficient root finding of polynomials over fields
- * of characteristic 2, in: Western European Workshop on Research in Cryptology
- * - WEWoRC 2009, Graz, Austria, LNCS, Springer, July 2009, to appear.
- * [2] [Zin96] V.A. Zinoviev. On the solution of equations of degree 10 over
- * finite fields GF(2^q). In Rapport de recherche INRIA no 2829, 1996.
  */
 
 #include 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools 3/3] nand-image-builder: Add more details in the help context

2016-06-01 Thread Boris Brezillon
Add explanation on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 nand-image-builder.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index d3d3f64..132f396 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -927,8 +927,21 @@ static void display_help(int status)
"-b --boot0 Build a 
boot0 image.\n"
"-s --scramble  
Scramble data\n"
"-a --address   Where 
the image will be programmed.\n"
-   "   This 
option is only required for non boot0 images that are meant to be programmed at 
a non eraseblock aligned offset.\n"
-   "\n");
+   "   This 
option is only required for non-boot0 images that are meant to be programmed at 
a non eraseblock aligned offset.\n"
+   "\n"
+   "Notes:\n"
+   "All the informations you need to pass to this tool should be 
part of the NAND datasheet.\n"
+   "If you are building a boot0 image, you'll have specify extra 
options, and these options should be chosen based on the layouts described here 
http://linux-sunxi.org/NAND#More_information_on_BROM_NAND\n;
+   "   --usable-page-size should be assigned the 'Hardware 
page' value\n"
+   "   --ecc should be assigned the 'ECC capacity'/'ECC page' 
values\n"
+   "   --usable-page-size should be smaller than --page-size\n"
+   "\n"
+   "Examples:\n"
+   "Building a boot0 image for the H27UCG8T2BTR-BC NAND which 
exposes 16k pages, 1280 OOB bytes per page, 4M eraseblocks, requires data 
scrambling and expect a minimum ECC of 40bits/1024bytes\n"
+   "   sunxi-nand-image-builder --boot0 --page-size 16384 
--oob-size 1280 --eraseblock-size 0x40 --scramble --boot0 
--usable-page-size 4096 --ecc 64/1024\n"
+   "Building a normal image for the same NAND\n"
+   "   sunxi-nand-image-builder --boot0 --page-size 16384 
--oob-size 1280 --eraseblock-size 0x40 --scramble --ecc 40/1024\n"
+   );
exit(status);
 }
 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH sunxi-tools 2/3] nand-image-builder: Add error messages to check_image_info()

2016-06-01 Thread Boris Brezillon
Add error messages explaining what is wrong or missing in the arguments
passed by to the sunxi-nand-image-builder tool.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 nand-image-builder.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/nand-image-builder.c b/nand-image-builder.c
index 34eee4f..d3d3f64 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -938,20 +938,37 @@ static int check_image_info(struct image_info *info)
int eccbytes, eccsteps;
unsigned i;
 
-   if (!info->page_size || !info->oob_size || !info->eraseblock_size ||
-   !info->usable_page_size)
+   if (!info->page_size) {
+   fprintf(stderr, "--page-size is missing\n");
return -EINVAL;
+   }
+
+   if (!info->page_size) {
+   fprintf(stderr, "--oob-size is missing\n");
+   return -EINVAL;
+   }
+
+   if (!info->eraseblock_size) {
+   fprintf(stderr, "--eraseblock-size is missing\n");
+   return -EINVAL;
+   }
 
-   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024)
+   if (info->ecc_step_size != 512 && info->ecc_step_size != 1024) {
+   fprintf(stderr, "Invalid ECC step argument: %d\n",
+   info->ecc_step_size);
return -EINVAL;
+   }
 
for (i = 0; i < ARRAY_SIZE(valid_ecc_strengths); i++) {
if (valid_ecc_strengths[i] == info->ecc_strength)
break;
}
 
-   if (i == ARRAY_SIZE(valid_ecc_strengths))
+   if (i == ARRAY_SIZE(valid_ecc_strengths)) {
+   fprintf(stderr, "Invalid ECC strength argument: %d\n",
+   info->ecc_strength);
return -EINVAL;
+   }
 
eccbytes = DIV_ROUND_UP(info->ecc_strength * 14, 8);
if (eccbytes % 2)
@@ -961,8 +978,11 @@ static int check_image_info(struct image_info *info)
eccsteps = info->usable_page_size / info->ecc_step_size;
 
if (info->page_size + info->oob_size <
-   info->usable_page_size + (eccsteps * (eccbytes)))
+   info->usable_page_size + (eccsteps * (eccbytes))) {
+   fprintf(stderr,
+   "ECC bytes do not fit in the NAND page, choose a weaker 
ECC\n");
return -EINVAL;
+   }
 
return 0;
 }
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-05-31 Thread Boris Brezillon
Hi Bernhard,

On Mon, 30 May 2016 23:23:31 +0200
Bernhard Nortmann <bernhard.nortm...@web.de> wrote:

> Am 30.05.2016 um 17:12 schrieb Boris Brezillon:
> > Generating raw NAND images is particularly useful for boot0 images
> > creation since the mainline driver is not supporting the funky layout
> > used by Allwinner's ROM code to load the boot0 binary from NAND.
> >
> > This tools also allows one to generate raw images for 'normal' partitions
> > so that they can be flashed before soldering on the NAND on the board
> > (using a regular NAND programmer).
> >
> > The tool takes care of generating ECC bytes and randomizing data as
> > expected by the NAND controller, and re-arranging the ECC/data sections
> > correctly.
> >
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > ---
> > Hi Siarhei,
> >
> > You seem to be the one maintaining the sunxi-tools repo, and I'm not sure
> > what's the process to submit patches (PR from github, or submitting
> > patches to the linux-sunxi ML).
> >
> > The tool I'm adding here is really useful when it comes to creating NAND
> > images, and I'd like to see it included in the sunxi-tools.
> >
> > Let me know if you have any questions.
> >
> > Thanks,
> >
> > Boris
> >
> >   Makefile |2 +-
> >   README.md|3 +
> >   nand-image-builder.c | 1122 
> > ++
> >   3 files changed, 1126 insertions(+), 1 deletion(-)
> >   create mode 100644 nand-image-builder.c
> >
> > diff --git a/Makefile b/Makefile
> > index 623dda1..434f084 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE
> >   endif
> >   
> >   # Tools useful on host and target
> > -TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part
> > +TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part 
> > sunxi-nand-image-builder  
> 
> Given the rather specific nature of this utility, I'm inclined to prefer 
> that
> it be added to the MISC_TOOLS target instead.

Sure.

> 
[...]

> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include   
> What's this include for? It breaks compilation for OSX 
> (https://travis-ci.org/n1tehawk/sunxi-tools/jobs/133998103)
> 
> > +#include   
> Same as above. Should be replaced by a generic "#include ".

Yep, will remove or modify these inclusions.

> 
> > +#include 
> > +#include   
> Again not available on OSX 
> (https://travis-ci.org/n1tehawk/sunxi-tools/jobs/134007716
> and https://travis-ci.org/n1tehawk/sunxi-tools/jobs/134013177)
> 
> You might want to have a look at the portable_endian.h available in our 
> include/
> subdir. Substituting '#include "portable_endian.h"' here seems to work fine.

Okay, I'll switch to protable_endian.h then.

[...]

> > +
> > +struct image_info {
> > +   int ecc_strength;
> > +   int ecc_step_size;
> > +   int page_size;
> > +   int oob_size;
> > +   int usable_page_size;
> > +   int eraseblock_size;
> > +   int scramble;
> > +   int boot0;
> > +   loff_t offset;  
> loff_t is gcc-specific(?), and once again breaks on OSX:
> https://travis-ci.org/n1tehawk/sunxi-tools/jobs/134014262
> 
> Is there a reason why the standard "off_t" is insufficient here?

Nope, I'll switch to off_t.

> 
> > +   const char *source;
> > +   const char *dest;
> > +};
> > +
[...]

> > +static inline int parity(unsigned int x)
> > +{
> > +   /*
> > +* public domain code snippet, lifted from
> > +* http://www-graphics.stanford.edu/~seander/bithacks.html
> > +*/
> > +   x ^= x >> 1;
> > +   x ^= x >> 2;
> > +   x = (x & 0xU) * 0xU;
> > +   return (x >> 28) & 1;
> > +}  
> Function parity() is unused, which makes clang unhappy:
> https://travis-ci.org/n1tehawk/sunxi-tools/jobs/133998102
> 
> If the code is supposed to remain, e.g. for clarity's sake / reference,
> I suggest enclosing it with "#if 0" [...] "#endif".

Nope, they should be removed, it's just that gcc was not complaining
about unused functions because of the inline specifier.

I'll remove all the functions you pointed as unused.

[...]

> 
> I have verified that with
> https://github.com/n1tehawk/sunxi-tools/commit/4f71a411e0b28b8c737c0e2948b0676ea4c78e8a
> applied, our build tests pass 
> (https://travis-ci.org/n1tehawk/sunxi-tools/builds/134018068).

Cool, I'll fix the implementation accordingly, send a PR and notify the
presence of new version on the ML (unless you want me to post a v2 of
this patch on the ML).

Thanks for the review and fixes.

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-05-30 Thread Boris Brezillon
On Mon, 30 May 2016 19:46:17 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:

> On Mon, 30 May 2016 17:24:16 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> 
> > Hi Hans,
> > 
> > On Mon, 30 May 2016 17:12:53 +0200
> > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> >   
> > > Generating raw NAND images is particularly useful for boot0 images
> > > creation since the mainline driver is not supporting the funky layout
> > > used by Allwinner's ROM code to load the boot0 binary from NAND.
> > > 
> > > This tools also allows one to generate raw images for 'normal' partitions
> > > so that they can be flashed before soldering on the NAND on the board
> > > (using a regular NAND programmer).
> > > 
> > > The tool takes care of generating ECC bytes and randomizing data as
> > > expected by the NAND controller, and re-arranging the ECC/data sections
> > > correctly.
> > 
> > Don't know how you want to proceed regarding NAND SPL image creation in
> > u-boot. We could either copy the sunxi-nand-image-builder sources in
> > u-boot or provide a macro to pass the sunxi-tools binaries path
> > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools
> > installed on his build platform.
> > 
> > Note that we'll need extra padding/concatenation steps to build an SPL
> > image suitable for MLC NANDs.  
> 
> Hi,
> 
> I guess, it is not a big secret that I'm also working on the SPI flash
> boot support at the moment. And some information about the progress is
> available here:
> 
> https://linux-sunxi.org/Bootable_SPI_flash
> 
> IMHO one of the most important requirements is to ensure that the device
> can be always unbricked by the end users in a very simple way. That's
> why I have added the SPI flash programming feature to the sunxi-fel
> tool and it is available in a wip branch since about a week ago:
> 
> https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip
> 
> There is still some work left to do. For example, just having SPI
> flash read/write functionality (which already works btw) is not
> good enough because it is not sufficiently foolproof. There will
> be a dedicated high level "spiflash-program" commmand to flash
> the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot.
> We had discussed this a bit on the IRC earlier:
> 
> http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894;
> 
> The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin
> image to automatically add some redundancy (two copies of the SPL):
> https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations
> And also pass some information about the SPI flash type via the SPL
> header (for example, the single/dual SPI mode, the maximum SPI clock
> speed, etc.). So that the SPL can use this information directly
> without any need to have extra code bloat responsible for doing
> runtime discovery of all these parameters.
> 
> But the most important foolproof feature would be of course a warning
> "You are trying to flash a firmware for an incompatible board, are
> you really sure?" :-) Later we can also have digital signatures
> verification built into the sunxi-fel, and other nice things.
> 
> 
> Boris, I think that your NAND use case is not very much different in
> principle. You can't expect the users to desolder the NAND chip and
> use an external NAND programmer tool when they need to unbrick their
> device, right?
> 

That's absolutely not the goal of this tool. It's just here to generate
raw NAND images.
Now, if there's a way to export NAND memory organization through the
SPL header, that's even better, but you'll still need this tool to
generate the image, and I think we should keep them separate.

The example I was giving was for people wanting to optimize their
production phase by pre-flashing the NANDs before soldering them.

Of course you'll be able to re-flash an existing system, but in this
case, except for the boot0 partition, you won't need a raw image,
because you're flashing the NAND with the sunxi NAND controller, and
it's able to generate the ECC bytes and scramble data appropriately.

I'll have a look at what you're currently working on, but I think this
patch is orthogonal to your sunxi-fel flasher.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-05-30 Thread Boris Brezillon
Hi Hans,

On Mon, 30 May 2016 17:12:53 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> Generating raw NAND images is particularly useful for boot0 images
> creation since the mainline driver is not supporting the funky layout
> used by Allwinner's ROM code to load the boot0 binary from NAND.
> 
> This tools also allows one to generate raw images for 'normal' partitions
> so that they can be flashed before soldering on the NAND on the board
> (using a regular NAND programmer).
> 
> The tool takes care of generating ECC bytes and randomizing data as
> expected by the NAND controller, and re-arranging the ECC/data sections
> correctly.

Don't know how you want to proceed regarding NAND SPL image creation in
u-boot. We could either copy the sunxi-nand-image-builder sources in
u-boot or provide a macro to pass the sunxi-tools binaries path
(SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools
installed on his build platform.

Note that we'll need extra padding/concatenation steps to build an SPL
image suitable for MLC NANDs.

Regards,

Boris

> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> Hi Siarhei,
> 
> You seem to be the one maintaining the sunxi-tools repo, and I'm not sure
> what's the process to submit patches (PR from github, or submitting
> patches to the linux-sunxi ML).
> 
> The tool I'm adding here is really useful when it comes to creating NAND
> images, and I'd like to see it included in the sunxi-tools.
> 
> Let me know if you have any questions.
> 
> Thanks,
> 
> Boris
> 
>  Makefile |2 +-
>  README.md|3 +
>  nand-image-builder.c | 1122 
> ++
>  3 files changed, 1126 insertions(+), 1 deletion(-)
>  create mode 100644 nand-image-builder.c
> 
> diff --git a/Makefile b/Makefile
> index 623dda1..434f084 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE
>  endif
>  
>  # Tools useful on host and target
> -TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part
> +TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part 
> sunxi-nand-image-builder
>  
>  # Symlinks to sunxi-fexc
>  FEXC_LINKS = bin2fex fex2bin
> diff --git a/README.md b/README.md
> index ada5432..b0d8788 100644
> --- a/README.md
> +++ b/README.md
> @@ -46,6 +46,9 @@ Manipulate PIO register dumps
>  ### sunxi-nand-part
>  Tool for manipulating Allwinner NAND partition tables
>  
> +### sunxi-nand-image-builder
> +Tool used to create raw NAND images (including boot0 images)
> +
>  ### jtag-loop.sunxi
>  ARM native boot helper to force the SD port into JTAG and then stop,
>  to ease debugging of bootloaders.
> diff --git a/nand-image-builder.c b/nand-image-builder.c
> new file mode 100644
> index 000..f3ad03c
> --- /dev/null
> +++ b/nand-image-builder.c
> @@ -0,0 +1,1122 @@
> +/*
> + * Generic binary BCH encoding/decoding library
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 51
> + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Copyright © 2011 Parrot S.A.
> + *
> + * Author: Ivan Djelic <ivan.dje...@parrot.com>
> + *
> + * Description:
> + *
> + * This library provides runtime configurable encoding/decoding of binary
> + * Bose-Chaudhuri-Hocquenghem (BCH) codes.
> + *
> + * Call init_bch to get a pointer to a newly allocated bch_control structure 
> for
> + * the given m (Galois field order), t (error correction capability) and
> + * (optional) primitive polynomial parameters.
> + *
> + * Call encode_bch to compute and store ecc parity bytes to a given buffer.
> + * Call decode_bch to detect and locate errors in received data.
> + *
> + * On systems supporting hw BCH features, intermediate results may be 
> provided
> + * to decode_bch in order to skip certain steps. See decode_bch() 
> documentation
> + * for details.
> + *
> + * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
> + * parameters m and t; thus allowing extra compiler optimizations and 
> providing
> + *

[linux-sunxi] [PATCH sunxi-tools] Add a tool to generate raw NAND images

2016-05-30 Thread Boris Brezillon
Generating raw NAND images is particularly useful for boot0 images
creation since the mainline driver is not supporting the funky layout
used by Allwinner's ROM code to load the boot0 binary from NAND.

This tools also allows one to generate raw images for 'normal' partitions
so that they can be flashed before soldering on the NAND on the board
(using a regular NAND programmer).

The tool takes care of generating ECC bytes and randomizing data as
expected by the NAND controller, and re-arranging the ECC/data sections
correctly.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Hi Siarhei,

You seem to be the one maintaining the sunxi-tools repo, and I'm not sure
what's the process to submit patches (PR from github, or submitting
patches to the linux-sunxi ML).

The tool I'm adding here is really useful when it comes to creating NAND
images, and I'd like to see it included in the sunxi-tools.

Let me know if you have any questions.

Thanks,

Boris

 Makefile |2 +-
 README.md|3 +
 nand-image-builder.c | 1122 ++
 3 files changed, 1126 insertions(+), 1 deletion(-)
 create mode 100644 nand-image-builder.c

diff --git a/Makefile b/Makefile
index 623dda1..434f084 100644
--- a/Makefile
+++ b/Makefile
@@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE
 endif
 
 # Tools useful on host and target
-TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part
+TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part 
sunxi-nand-image-builder
 
 # Symlinks to sunxi-fexc
 FEXC_LINKS = bin2fex fex2bin
diff --git a/README.md b/README.md
index ada5432..b0d8788 100644
--- a/README.md
+++ b/README.md
@@ -46,6 +46,9 @@ Manipulate PIO register dumps
 ### sunxi-nand-part
 Tool for manipulating Allwinner NAND partition tables
 
+### sunxi-nand-image-builder
+Tool used to create raw NAND images (including boot0 images)
+
 ### jtag-loop.sunxi
 ARM native boot helper to force the SD port into JTAG and then stop,
 to ease debugging of bootloaders.
diff --git a/nand-image-builder.c b/nand-image-builder.c
new file mode 100644
index 000..f3ad03c
--- /dev/null
+++ b/nand-image-builder.c
@@ -0,0 +1,1122 @@
+/*
+ * Generic binary BCH encoding/decoding library
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Copyright © 2011 Parrot S.A.
+ *
+ * Author: Ivan Djelic <ivan.dje...@parrot.com>
+ *
+ * Description:
+ *
+ * This library provides runtime configurable encoding/decoding of binary
+ * Bose-Chaudhuri-Hocquenghem (BCH) codes.
+ *
+ * Call init_bch to get a pointer to a newly allocated bch_control structure 
for
+ * the given m (Galois field order), t (error correction capability) and
+ * (optional) primitive polynomial parameters.
+ *
+ * Call encode_bch to compute and store ecc parity bytes to a given buffer.
+ * Call decode_bch to detect and locate errors in received data.
+ *
+ * On systems supporting hw BCH features, intermediate results may be provided
+ * to decode_bch in order to skip certain steps. See decode_bch() documentation
+ * for details.
+ *
+ * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of
+ * parameters m and t; thus allowing extra compiler optimizations and providing
+ * better (up to 2x) encoding performance. Using this option makes sense when
+ * (m,t) are fixed and known in advance, e.g. when using BCH error correction
+ * on a particular NAND flash device.
+ *
+ * Algorithmic details:
+ *
+ * Encoding is performed by processing 32 input bits in parallel, using 4
+ * remainder lookup tables.
+ *
+ * The final stage of decoding involves the following internal steps:
+ * a. Syndrome computation
+ * b. Error locator polynomial computation using Berlekamp-Massey algorithm
+ * c. Error locator root finding (by far the most expensive step)
+ *
+ * In this implementation, step c is not performed using the usual Chien 
search.
+ * Instead, an alternative approach described in [1] is used. It consists in
+ * factoring the error locator polynomial using the Berlekamp Trace algorithm
+ * (BTA) down to a certain degree (4), after which ad hoc low-degree polynomial
+ * solving techniques [2] are used. The resulting algorithm, called BTZ, yields
+ * much better performance than Chien search for usual (m,t) values (typically
+ * m >= 13, t < 32, see [1]).
+ *
+ * [1] B. 

[linux-sunxi] [PATCH 0/7] spl: nand: sunxi: implement auto-detection

2016-05-20 Thread Boris Brezillon
Hello,

This patch series aims at adding support for NAND auto-detection to
the sunxi SPL NAND driver.

As explained in patch 7, this auto-detection is nothing more than a
dumb "trial and error" logic, but it allows one to use the same
SPL binary for all kind of sunxi boards booting from NAND.
Of course, this approach might increase a bit the boot-time, but this
is something we could address by adding a "default NAND config",
that would be tested before launching the auto-detection procedure.

Now let's detail a bit what's inside this patch-set.
Patch 1 is a cleanup removing support for BootROM configs, which in
my opinion are not only inefficient but also not reliable (at least
the current implementation does not guarantee that you'll be using
the correct configuration when reading the NAND).

Piotr, Hans, any comment?
Is this a real problem if we get rid of syndrome/BootROM configs?
I mean, are you really using this mode? If that's not the case, I'd
prefer dropping support for this feature. ITOH, if you really
need this mode, then I'd recommend adding Kconfig options to specify
the exact config to be used rather than randomly testing configs
(see my explanation in patch 1).

Patch 2 is renaming the SYS_NAND_U_BOOT_OFFS Kconfig option to make it
usable on all platforms (not only sunxi) and avoid conflicts when
one board is defining CONFIG_SYS_NAND_U_BOOT_OFFS in its
include/configs/.h header.

Patch 3 is adding generic support for redundant u-boot images, which
is particularly useful on modern NANDs where corruptions is likely to
happen.
Patch 4 is just getting rid of the open-coded version of redundant
u-boot image support in the sunxi NAND driver.

Patch 5 is a simple improvement of the NAND controller status polling
loop, which is really important to make the "trial and error"
approach efficient (we try to limit the impact on boot-time here).
Patch 6 and 7 are implementing the auto-detection logic.


Best Regards,

Boris

Boris Brezillon (7):
  spl: nand: sunxi: remove support for so-called 'syndrome' mode
  spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
  spl: nand: support redundant u-boot image
  spl: nand: sunxi: stop guessing the redundant u-boot offset
  spl: nand: sunxi: rework status polling loop
  spl: nand: sunxi: split 'load page' and 'read page' logic
  spl: nand: sunxi: add support for NAND config auto-detection

 common/spl/spl_nand.c |  12 +
 drivers/mtd/nand/Kconfig  |  15 +-
 drivers/mtd/nand/sunxi_nand_spl.c | 480 --
 3 files changed, 332 insertions(+), 175 deletions(-)

-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 1/7] spl: nand: sunxi: remove support for so-called 'syndrome' mode

2016-05-20 Thread Boris Brezillon
The sunxi SPL NAND controller driver supports use 'BootROM'-like configs,
that is, configs where the ECC bytes and real data are interleaved in the
page instead of putting ECC bytes in the OOB area.

Doing that has several drawbacks:
- since you're interleaving data and ECC bytes you can't use the whole page
  otherwise you might override the bad block marker with non-FF bytes.
- to solve the bad block marker problem, the ROM code supports partially
  using the page, but this introduces a huge penalty both in term of read
  speed and NAND memory usage. While this is fine for rather small
  binaries(like the SPL one which is at maximum 24KB large), it becomes
  non-negligible for the bootloader image (several hundred of KB).
- auto-detection of the page size is not reliable (this is in my opinion
  the biggest problem). If you get the page size wrong, you'll end up
  reading data at a different offset than what was specified by the caller
  and the reading may succeed (if valid data were written at this address).

For all those reasons I think it's wiser to completely remove support for
'syndrome' configs. If we ever need to support it again, then I'd recommend
specifying all the config parameters through Kconfig options.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 56 ++-
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b0e07aa..1739da2 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,9 +119,6 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-/* random seed used for syndrome calls */
-const uint16_t random_seed_syndrome = 0x4a80;
-
 #define MAX_RETRIES 10
 
 static int check_value_inner(int offset, int expected_bits,
@@ -183,7 +180,7 @@ void nand_init(void)
 }
 
 static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -209,17 +206,11 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
page = real_addr / page_size;
column = real_addr % page_size;
 
-   if (syndrome)
-   column += (column / ecc_page_size) * ecc_off;
-
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   if (syndrome)
-   rand_seed = random_seed_syndrome;
-   else
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % 128];
 
writel((rand_seed << 16) | NFC_ECC_RANDOM_EN | NFC_ECC_EN
| NFC_ECC_PIPELINE | (ecc_mode << 12),
@@ -228,9 +219,8 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome)
-   writel(page_size + (column / ecc_page_size) * ecc_off,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
@@ -266,7 +256,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
NFC_PAGE_CMD | NFC_WAIT_FLAG |
((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
-   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
+   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
@@ -292,7 +282,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
 }
 
 static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest, int syndrome)
+   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
 {
void *end = dest + size;
 
@@ -301,16 +291,14 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 
for ( ;dest < end; dest += ecc_page_size, offs += ecc_page_size) {
if (nand_read_page(page_size, ecc_strength, ecc_page_size,
-  addr_cycles, offs, (dma_addr_t)dest,
-  syndrome))
+  addr_cycles, offs, (dma_addr_t)dest))
return -1;
}
 
return 0;
 }
 
-static int nand_read_buffer(uint32_t offs, un

[linux-sunxi] [PATCH 5/7] spl: nand: sunxi: rework status polling loop

2016-05-20 Thread Boris Brezillon
check_value_xxx() helpers are using a 1ms delay between each test, which
can be quite long for some operations (like a page read on an SLC NAND).
Since we don't have anything to do but to poll this register, reduce the
delay between each test to 1us.

While we're at it, rename the max_number_of_retries parameters and the
MAX_RETRIES macro into timeout_us and DEFAULT_TIMEOUT_US to reflect that
we're actually waiting a given amount of time and not only a number of
retries.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 13e6eab..55b3c8a 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,35 +119,31 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-#define MAX_RETRIES 10
+#define DEFAULT_TIMEOUT_US 10
 
 static int check_value_inner(int offset, int expected_bits,
-   int max_number_of_retries, int negation)
+int timeout_us, int negation)
 {
-   int retries = 0;
do {
int val = readl(offset) & expected_bits;
if (negation ? !val : val)
return 1;
-   mdelay(1);
-   retries++;
-   } while (retries < max_number_of_retries);
+   udelay(1);
+   } while (--timeout_us);
 
return 0;
 }
 
 static inline int check_value(int offset, int expected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, expected_bits,
-   max_number_of_retries, 0);
+   return check_value_inner(offset, expected_bits, timeout_us, 0);
 }
 
 static inline int check_value_negated(int offset, int unexpected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, unexpected_bits,
-   max_number_of_retries, 1);
+   return check_value_inner(offset, unexpected_bits, timeout_us, 1);
 }
 
 void nand_init(void)
@@ -162,7 +158,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CTL);
 
if (!check_value_negated(SUNXI_NFC_BASE + NFC_CTL,
-NFC_CTL_RESET, MAX_RETRIES)) {
+NFC_CTL_RESET, DEFAULT_TIMEOUT_US)) {
printf("Couldn't initialize nand\n");
}
 
@@ -172,7 +168,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error timeout waiting for nand reset\n");
return;
}
@@ -260,14 +256,15 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error while initializing dma interrupt\n");
return -1;
}
writel(NFC_ST_DMA_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
-SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
+SUNXI_DMA_DDMA_CFG_REG_LOADING,
+DEFAULT_TIMEOUT_US)) {
printf("Error while waiting for dma transfer to finish\n");
return -1;
}
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-05-20 Thread Boris Brezillon
NAND chips are supposed to expose their capabilities through advanced
mechanisms like READID, ONFI or JEDEC parameter tables. While those
methods are appropriate for the bootloader itself, it's way to
complicated and takes too much space to fit in the SPL.

Replace those mechanisms by a dumb 'trial and error' mechanism.

With this new approach we can get rid of the fixed config list that was
used in the sunxi NAND SPL driver.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 262 +-
 1 file changed, 204 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b43f2af..cc2e69b 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -103,6 +103,7 @@ struct nfc_config {
int addr_cycles;
int nseeds;
bool randomize;
+   bool valid;
 };
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
@@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
u32 offs)
return 0;
 }
 
+static int nand_reset_column(void)
+{
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
+  (1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static int nand_read_page(const struct nfc_config *conf, u32 offs,
  void *dest, int len)
 {
@@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config *conf, 
u32 offs,
return (val & 0x1) ? 1 : 0;
 }
 
-static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
+static int nand_max_ecc_strength(struct nfc_config *conf)
 {
-   void *end = dest + size;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
-   struct nfc_config conf = {
-   .page_size = page_size,
-   .ecc_size = ecc_page_size,
-   .addr_cycles = addr_cycles,
-   .nseeds = ARRAY_SIZE(random_seed),
-   .randomize = true,
-   };
+   static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
};
+   int max_oobsize, max_ecc_bytes;
+   int nsectors = conf->page_size / conf->ecc_size;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   conf.ecc_strength = i;
+   /*
+* ECC strength is limited by the size of the OOB area which is
+* correlated with the page size.
+*/
+   switch (conf->page_size) {
+   case 2048:
+   max_oobsize = 64;
+   break;
+   case 4096:
+   max_oobsize = 256;
+   break;
+   case 8196:
+   max_oobsize = 620;
+   break;
+   case 16384:
+   max_oobsize = 1664;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   max_ecc_bytes = max_oobsize / nsectors;
+
+   for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
+   if (ecc_bytes[i] > max_ecc_bytes)
break;
-   }
}
 
+   if (!i)
+   return -EINVAL;
 
-   nand_apply_config();
+   return i - 1;
+}
 
-   for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
-   if (nand_load_page(, offs))
-   return -1;
+static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
+ void *dest)
+{
+   /* NAND with pages > 4k will likely require 1k sector size. */
+   int min_ecc_size = conf->page_size > 4096 ? 1024 : 512;
+   int page = offs / conf->page_size;
+   int ret;
 
-   if (nand_read_page(, offs, dest, page_size))
-   return -1;
+   /*
+* In most cases, 1k sectors are preferred over 512b ones, start
+* testing this config first.
+*/
+   for (conf->ecc_size = 1024; conf->ecc_size >= min_ecc_size;
+conf->ecc_size >>= 1) {
+   int max_ecc_strength = nand_max_ecc_strength(conf);
+
+   nand_apply_config(conf);
+
+   /*
+   

[linux-sunxi] [PATCH 4/7] spl: nand: sunxi: stop guessing the redundant u-boot offset

2016-05-20 Thread Boris Brezillon
Use CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND value instead of trying to guess
where the redundant u-boot image is based on simple (and most of the time
erroneous) heuristics.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 85cb127..13e6eab 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -344,26 +344,6 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest)
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
-   /*
-* u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
-* for backup u-boot 1 erase block further.
-*/
-   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
-   const uint32_t boot_offsets[] = {
-   CONFIG_SPL_NAND_U_BOOT_OFFS,
-   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
-   };
-   int i;
-
-   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
-   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
-   if (nand_read_buffer(boot_offsets[i], size,
-dest) == 0)
-   return 0;
-   }
-   return -1;
-   }
-
return nand_read_buffer(offs, size, dest);
 }
 
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 3/7] spl: nand: support redundant u-boot image

2016-05-20 Thread Boris Brezillon
On modern NAND it's more than recommended to have a backup copy of the
u-boot binary to recover from corruption: bitflips are quite common on
MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
more quickly than what you would see on an SLC NAND.

Add an extra Kconfig option to specify the offset of the redundant u-boot
image.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 common/spl/spl_nand.c| 8 
 drivers/mtd/nand/Kconfig | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 612bd4a..0bf0848 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -12,6 +12,9 @@
 
 #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
 #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND
+#else
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
 #endif
 
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
@@ -111,6 +114,11 @@ int spl_nand_load_image(void)
 #endif
/* Load u-boot */
err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
+#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
+   if (err)
+   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
+   header);
+#endif
nand_deselect();
return err;
 }
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4b0f92c..2f1d1f7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -110,6 +110,12 @@ config SPL_NAND_U_BOOT_OFFS
Set the offset from the start of the nand where u-boot should be
loaded from.
 
+config SPL_NAND_U_BOOT_OFFS_REDUND
+   hex "Location in NAND to read U-Boot from"
+   default SPL_NAND_U_BOOT_OFFS
+   help
+   Set the offset from the start of the nand where u-boot should be
+   loaded from.
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 6/7] spl: nand: sunxi: split 'load page' and 'read page' logic

2016-05-20 Thread Boris Brezillon
Split the 'load page' and 'read page' logic in 2 different functions so
we can later load the page and test different ECC configs without the
penalty of reloading the same page in the NAND cache.

We also move common setup to a dedicated function (nand_apply_config()) to
avoid rewriting the same values in NFC registers each time we read a page.

These new functions are passed a pointer to an nfc_config struct to limit
the number of parameters.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand_spl.c | 185 +++---
 1 file changed, 114 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 55b3c8a..b43f2af 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -66,6 +66,8 @@
 #define NFC_ROW_AUTO_INC   (1 << 27)
 #define NFC_SEND_CMD3  (1 << 28)
 #define NFC_SEND_CMD4  (1 << 29)
+#define NFC_RAW_CMD(0 << 30)
+#define NFC_PAGE_CMD   (2 << 30)
 
 #define NFC_ST_CMD_INT_FLAG(1 << 1)
 #define NFC_ST_DMA_INT_FLAG(1 << 2)
@@ -78,9 +80,6 @@
 #define NFC_CMD_RNDOUT 0x05
 #define NFC_CMD_READSTART  0x30
 
-
-#define NFC_PAGE_CMD   (2 << 30)
-
 #define SUNXI_DMA_CFG_REG0  0x300
 #define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
 #define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
@@ -97,6 +96,15 @@
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
 
+struct nfc_config {
+   int page_size;
+   int ecc_strength;
+   int ecc_size;
+   int addr_cycles;
+   int nseeds;
+   bool randomize;
+};
+
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
 /* random seed used by linux */
@@ -175,50 +183,70 @@ void nand_init(void)
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 }
 
-static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
+static void nand_apply_config(const struct nfc_config *conf)
 {
-   uint32_t val;
-   int i, ecc_off = 0;
-   uint16_t ecc_mode = 0;
-   uint16_t rand_seed;
-   uint32_t page;
-   uint16_t column;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+   u32 val;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   ecc_mode = i;
-   break;
-   }
+   val = readl(SUNXI_NFC_BASE + NFC_CTL);
+   val &= ~NFC_CTL_PAGE_SIZE_MASK;
+   writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
+  SUNXI_NFC_BASE + NFC_CTL);
+   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
+   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
+}
+
+static int nand_load_page(const struct nfc_config *conf, u32 offs)
+{
+   int page = offs / conf->page_size;
+
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(((page & 0x) << 16), SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
+   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
+  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -EIO;
}
 
-   /* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
-   /* HW ECC always work with even numbers of ECC bytes */
-   ecc_off += (ecc_off & 1);
-   ecc_off += 4; /* prepad */
+   return 0;
+}
+
+static int nand_read_page(const struct nfc_config *conf, u32 offs,
+ void *dest, int len)
+{
+   dma_addr_t dst = (dma_addr_t)dest;
+   int nsectors = len / conf->ecc_size;
+   u16 rand_seed;
+   u32 val;
+   int page;
+
+   page = offs / conf->page_size;
 
-   page = real_addr / page_size;
-   column = real_addr % page_size;
+   if (offs % conf->page_size || len % conf->ecc_size ||
+   len > conf->page_size || len < 0)
+   return -EINVAL;
 
/* clear ecc status */
   

[linux-sunxi] [PATCH 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

2016-05-20 Thread Boris Brezillon
The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
to explicitly depend on platforms that are not already defining it in their
include/configs/.h header.

Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency
on NAND_SUNXI and make it dependent on SPL selection.

common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to
CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay
compatible with the existing behavior.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 common/spl/spl_nand.c | 4 
 drivers/mtd/nand/Kconfig  | 9 +
 drivers/mtd/nand/sunxi_nand_spl.c | 8 
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index bbd9546..612bd4a 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -10,6 +10,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#endif
+
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
 int spl_nand_load_image(void)
 {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2fc73ef..4b0f92c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -99,16 +99,17 @@ config SYS_NAND_BUSWIDTH_16BIT
not available while configuring controller. So a static 
CONFIG_NAND_xx
is needed to know the device's bus-width in advance.
 
-# Enhance depends when converting drivers to Kconfig which use this config
-config SYS_NAND_U_BOOT_OFFS
+if SPL
+
+# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS.
+# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined.
+config SPL_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
-   depends on NAND_SUNXI
help
Set the offset from the start of the nand where u-boot should be
loaded from.
 
-if SPL
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 1739da2..85cb127 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -348,14 +348,14 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
 * u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
 * for backup u-boot 1 erase block further.
 */
-   const uint32_t eraseblock_size = CONFIG_SYS_NAND_U_BOOT_OFFS / 2;
+   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
const uint32_t boot_offsets[] = {
-   CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_U_BOOT_OFFS + eraseblock_size,
+   CONFIG_SPL_NAND_U_BOOT_OFFS,
+   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
};
int i;
 
-   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
+   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
if (nand_read_buffer(boot_offsets[i], size,
 dest) == 0)
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot

2016-05-16 Thread Boris Brezillon
Hi Scott,

On Tue, 03 May 2016 00:06:45 -0500
Scott Wood <o...@buserror.net> wrote:

> On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote:
> > On Mon, 25 Apr 2016 13:36:46 -0400
> > Tom Rini <tr...@konsulko.com> wrote:
> >   
> > > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> > >   
> > > > Hi Scott,
> > > > 
> > > > I've recently contributed a lot of MTD/NAND related patches (and intend
> > > > to continue doing so). Some of them are transversal changes touching the
> > > > MTD and NAND framework internals, which implies patching all NAND
> > > > drivers along with the core changes.
> > > > 
> > > > All those changes are required to properly handle modern NANDs (MLC/TLC
> > > > NANDs), and I need them to add proper NAND support to the sunxi
> > > > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > > > 
> > > > So my question is, how should I port those changes to U-Boot? I see
> > > > that your doing "synchronization commits", but in my case this mean
> > > > including a bunch of driver specific changes into this "sync commit".
> > > > 
> > > > I think it's also worth mentioning that I plan to heavily rework the
> > > > Linux NAND framework to improve NAND performances on modern NAND
> > > > controllers and clarify the NAND chip / NAND controller concepts, and
> > > > other people are also working on merging the BBT code of the NAND and
> > > > OneNAND framework. Which unfortunately means that we're not done porting
> > > > invasive changes to U-Boot :-/.
> > > > 
> > > > Any advice is welcome.
> > > 
> > > I suppose my first suggestion would be to sync the kernel back into
> > > U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> > > be too hard to pick a window to grab the current kernel release and
> > > bring it over.  I think the more stuff we let build up prior to syncing
> > > the harder it will be.
> > >   
> > 
> > Okay, so this means I should be the one back-porting Linux changes into
> > U-Boot? I was planning on porting my current work on the sunxi NAND
> > driver (including all the core dependencies) and submitting it to
> > U-Boot, but honestly, I don't see how I can keep things in sync in the
> > long run. From my experience, porting things to U-Boot is never as
> > easy at it seems, and I don't think I'll have the time to maintain that
> > by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
> > Can I expect some help from your side?  
> 
> I usually do syncs when someone complains about needing a sync.  Every release
> seems a bit much.  I'll try to do one soon.

Sorry to bother you with that, but can I ask when you plan to do this
sync (I guess you'll sync with 4.6)? As I explained, I depend on
features introduced in 4.6 to make the sunxi NAND driver usable on
sunxi based boards (the concept of data randomizer/scrambler is
required on some MLC NANDs, and most Allwinner boards embed this
kind of NAND chips).

Don't hesitate to let me know if you need some help.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot

2016-05-03 Thread Boris Brezillon
Hi Scott,

On Tue, 03 May 2016 00:06:45 -0500
Scott Wood <o...@buserror.net> wrote:

> On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote:
> > On Mon, 25 Apr 2016 13:36:46 -0400
> > Tom Rini <tr...@konsulko.com> wrote:
> >   
> > > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> > >   
> > > > Hi Scott,
> > > > 
> > > > I've recently contributed a lot of MTD/NAND related patches (and intend
> > > > to continue doing so). Some of them are transversal changes touching the
> > > > MTD and NAND framework internals, which implies patching all NAND
> > > > drivers along with the core changes.
> > > > 
> > > > All those changes are required to properly handle modern NANDs (MLC/TLC
> > > > NANDs), and I need them to add proper NAND support to the sunxi
> > > > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > > > 
> > > > So my question is, how should I port those changes to U-Boot? I see
> > > > that your doing "synchronization commits", but in my case this mean
> > > > including a bunch of driver specific changes into this "sync commit".
> > > > 
> > > > I think it's also worth mentioning that I plan to heavily rework the
> > > > Linux NAND framework to improve NAND performances on modern NAND
> > > > controllers and clarify the NAND chip / NAND controller concepts, and
> > > > other people are also working on merging the BBT code of the NAND and
> > > > OneNAND framework. Which unfortunately means that we're not done porting
> > > > invasive changes to U-Boot :-/.
> > > > 
> > > > Any advice is welcome.
> > > 
> > > I suppose my first suggestion would be to sync the kernel back into
> > > U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> > > be too hard to pick a window to grab the current kernel release and
> > > bring it over.  I think the more stuff we let build up prior to syncing
> > > the harder it will be.
> > >   
> > 
> > Okay, so this means I should be the one back-porting Linux changes into
> > U-Boot? I was planning on porting my current work on the sunxi NAND
> > driver (including all the core dependencies) and submitting it to
> > U-Boot, but honestly, I don't see how I can keep things in sync in the
> > long run. From my experience, porting things to U-Boot is never as
> > easy at it seems, and I don't think I'll have the time to maintain that
> > by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
> > Can I expect some help from your side?  
> 
> I usually do syncs when someone complains about needing a sync.  Every release
> seems a bit much.  I'll try to do one soon.

Great! Let me know if you need some help.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v4 09/11] drm: sun4i: tv: Add NTSC output standard

2016-04-26 Thread Boris Brezillon
On Mon, 25 Apr 2016 15:22:50 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Add the settings to support the NTSC standard.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  drivers/gpu/drm/sun4i/sun4i_tv.c | 45 
> 
>  1 file changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index ccf275a90132..bc047f923508 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -178,24 +178,69 @@ struct sun4i_tv {
>   struct sun4i_drv*drv;
>  };
>  
> +struct video_levels ntsc_video_levels = {
> + .black = 282,   .blank = 240,
> +};
> +
>  struct video_levels pal_video_levels = {
>   .black = 252,   .blank = 252,
>  };
>  
> +struct burst_levels ntsc_burst_levels = {
> + .cb = 79,   .cr = 0,
> +};
> +
>  struct burst_levels pal_burst_levels = {
>   .cb = 40,   .cr = 40,
>  };
>  
> +struct color_gains ntsc_color_gains = {
> + .cb = 160,  .cr = 160,
> +};
> +
>  struct color_gains pal_color_gains = {
>   .cb = 224,  .cr = 224,
>  };
>  
> +struct resync_parameters ntsc_resync_parameters = {
> + .field = false, .line = 14, .pixel = 12,
> +};
> +
>  struct resync_parameters pal_resync_parameters = {
>   .field = true,  .line = 13, .pixel = 12,
>  };
>  
>  struct tv_mode tv_modes[] = {
>   {
> + .name   = "NTSC",
> + .mode   = SUN4I_TVE_CFG0_RES_480i,
> + .chroma_freq= 0x21f07c1f,
> + .yc_en  = true,
> + .dac3_en= true,
> + .dac_bit25_en   = true,
> +
> + .back_porch = 118,
> + .front_porch= 32,
> + .line_number= 525,
> +
> + .hdisplay   = 720,
> + .hfront_porch   = 18,
> + .hsync_len  = 2,
> + .hback_porch= 118,
> +
> + .vdisplay   = 480,
> + .vfront_porch   = 26,
> + .vsync_len  = 2,
> + .vback_porch= 17,
> +
> + .vblank_level   = 240,
> +
> + .color_gains= _color_gains,
> + .burst_levels   = _burst_levels,
> + .video_levels   = _video_levels,
> + .resync_params  = _resync_parameters,
> + },
> + {
>   .name   = "PAL",
>   .mode   = SUN4I_TVE_CFG0_RES_576i,
>   .chroma_freq= 0x2a098acb,



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v4 08/11] drm: sun4i: tv: Add PAL output standard

2016-04-26 Thread Boris Brezillon
On Mon, 25 Apr 2016 15:22:49 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Now that we have support for the composite output, we can start adding new
> supported standards. Start with PAL, and we will add other eventually.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  drivers/gpu/drm/sun4i/sun4i_tv.c | 42 
> 
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 78634dfc0f77..ccf275a90132 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -178,7 +178,49 @@ struct sun4i_tv {
>   struct sun4i_drv*drv;
>  };
>  
> +struct video_levels pal_video_levels = {
> + .black = 252,   .blank = 252,
> +};
> +
> +struct burst_levels pal_burst_levels = {
> + .cb = 40,   .cr = 40,
> +};
> +
> +struct color_gains pal_color_gains = {
> + .cb = 224,  .cr = 224,
> +};
> +
> +struct resync_parameters pal_resync_parameters = {
> + .field = true,  .line = 13, .pixel = 12,
> +};
> +
>  struct tv_mode tv_modes[] = {
> + {
> + .name   = "PAL",
> + .mode   = SUN4I_TVE_CFG0_RES_576i,
> + .chroma_freq= 0x2a098acb,
> +
> + .back_porch = 138,
> + .front_porch= 24,
> + .line_number= 625,
> +
> + .hdisplay   = 720,
> + .hfront_porch   = 3,
> + .hsync_len  = 2,
> + .hback_porch= 139,
> +
> + .vdisplay   = 576,
> + .vfront_porch   = 28,
> + .vsync_len  = 2,
> + .vback_porch= 19,
> +
> + .vblank_level   = 252,
> +
> + .color_gains= _color_gains,
> +     .burst_levels   = _burst_levels,
> + .video_levels   = _video_levels,
> + .resync_params  = _resync_parameters,
> + },
>  };
>  
>  static inline struct sun4i_tv *



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v4 07/11] drm: sun4i: Add composite output

2016-04-26 Thread Boris Brezillon
On Mon, 25 Apr 2016 15:22:48 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Some Allwinner SoCs have an IP called the TV encoder that is used to output
> composite and VGA signals. In such a case, we need to use the second TCON
> channel.
> 
> Add support for that TV encoder.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  drivers/gpu/drm/sun4i/Makefile   |   2 +
>  drivers/gpu/drm/sun4i/sun4i_tv.c | 621 
> +++
>  2 files changed, 623 insertions(+)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_tv.c
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 74f804b88ff5..58cd55149827 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,3 +9,5 @@ sun4i-tcon-y += sun4i_dotclock.o
>  
>  obj-$(CONFIG_DRM_SUN4I)  += sun4i-drm.o sun4i-tcon.o
>  obj-$(CONFIG_DRM_SUN4I)  += sun4i_backend.o
> +
> +obj-$(CONFIG_DRM_SUN4I)  += sun4i_tv.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> new file mode 100644
> index ..78634dfc0f77
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -0,0 +1,621 @@
> +/*
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * Maxime Ripard <maxime.rip...@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_backend.h"
> +#include "sun4i_drv.h"
> +#include "sun4i_tcon.h"
> +
> +#define SUN4I_TVE_EN_REG 0x000
> +#define SUN4I_TVE_EN_DAC_MAP_MASKGENMASK(19, 4)
> +#define SUN4I_TVE_EN_DAC_MAP(dac, out)   (((out) & 0xf) << (dac 
> + 1) * 4)
> +#define SUN4I_TVE_EN_ENABLE  BIT(0)
> +
> +#define SUN4I_TVE_CFG0_REG   0x004
> +#define SUN4I_TVE_CFG0_DAC_CONTROL_54M   BIT(26)
> +#define SUN4I_TVE_CFG0_CORE_DATAPATH_54M BIT(25)
> +#define SUN4I_TVE_CFG0_CORE_CONTROL_54M  BIT(24)
> +#define SUN4I_TVE_CFG0_YC_EN BIT(17)
> +#define SUN4I_TVE_CFG0_COMP_EN   BIT(16)
> +#define SUN4I_TVE_CFG0_RES(x)((x) & 0xf)
> +#define SUN4I_TVE_CFG0_RES_480i  SUN4I_TVE_CFG0_RES(0)
> +#define SUN4I_TVE_CFG0_RES_576i  SUN4I_TVE_CFG0_RES(1)
> +
> +#define SUN4I_TVE_DAC0_REG   0x008
> +#define SUN4I_TVE_DAC0_CLOCK_INVERT  BIT(24)
> +#define SUN4I_TVE_DAC0_LUMA(x)   (((x) & 3) << 20)
> +#define SUN4I_TVE_DAC0_LUMA_0_4  SUN4I_TVE_DAC0_LUMA(3)
> +#define SUN4I_TVE_DAC0_CHROMA(x) (((x) & 3) << 18)
> +#define SUN4I_TVE_DAC0_CHROMA_0_75   SUN4I_TVE_DAC0_CHROMA(3)
> +#define SUN4I_TVE_DAC0_INTERNAL_DAC(x)   (((x) & 3) << 16)
> +#define SUN4I_TVE_DAC0_INTERNAL_DAC_37_5_OHMS
> SUN4I_TVE_DAC0_INTERNAL_DAC(3)
> +#define SUN4I_TVE_DAC0_DAC_EN(dac)   BIT(dac)
> +
> +#define SUN4I_TVE_NOTCH_REG  0x00c
> +#define SUN4I_TVE_NOTCH_DAC0_TO_DAC_DLY(dac, x)  ((4 - (x)) << (dac * 3))
> +
> +#define SUN4I_TVE_CHROMA_FREQ_REG0x010
> +
> +#define SUN4I_TVE_PORCH_REG  0x014
> +#define SUN4I_TVE_PORCH_BACK(x)  ((x) << 16)
> +#define SUN4I_TVE_PORCH_FRONT(x) (x)
> +
> +#define SUN4I_TVE_LINE_REG   0x01c
> +#define SUN4I_TVE_LINE_FIRST(x)  ((x) << 16)
> +#define SUN4I_TVE_LINE_NUMBER(x) (x)
> +
> +#define SUN4I_TVE_LEVEL_REG  0x020
> +#define SUN4I_TVE_LEVEL_BLANK(x) ((x) << 16)
> +#define SUN4I_TVE_LEVEL_BLACK(x) (x)
> +
> +#define SUN4I_TVE_DAC1_REG   0x024
> +#define SUN4I_TVE_DAC1_AMPLITUDE(dac, x) ((x) << (dac * 8))
> +
> +#define SUN4I_TVE_DETECT_STA_REG 0x038
> +#define SUN4I_TVE_DETECT_STA_DAC(dac)BIT((dac * 8))
> +#define SUN4I_TVE_DETECT_STA_UNCONNECTED 0
> +#define SUN4I_TVE_DETECT_STA_CONNECTED   1
> +#define SUN4I_TVE_DETECT_STA_GROUND  2
> +
> +#de

[linux-sunxi] Re: [PATCH v4 06/11] drm: sun4i: Add RGB output

2016-04-26 Thread Boris Brezillon
On Mon, 25 Apr 2016 15:22:47 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> One of the A10 display pipeline possible output is an RGB interface to
> drive LCD panels directly. This is done through the first channel of the
> TCON that will output our video signals directly.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  24 
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  | 250 
> +
>  drivers/gpu/drm/sun4i/sun4i_rgb.h  |  18 +++
>  drivers/gpu/drm/sun4i/sun4i_tcon.c |  61 -
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |   2 +
>  6 files changed, 355 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.h
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 6df3ef32732d..74f804b88ff5 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -4,6 +4,7 @@ sun4i-drm-y += sun4i_framebuffer.o
>  sun4i-drm-y += sun4i_layer.o
>  
>  sun4i-tcon-y += sun4i_tcon.o
> +sun4i-tcon-y += sun4i_rgb.o
>  sun4i-tcon-y += sun4i_dotclock.o
>  
>  obj-$(CONFIG_DRM_SUN4I)  += sun4i-drm.o sun4i-tcon.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index a081969673ac..891d434ea57f 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -222,6 +222,11 @@ static bool sun4i_drv_node_is_frontend(struct 
> device_node *node)
>  "allwinner,sun5i-a13-display-frontend");
>  }
>  
> +static bool sun4i_drv_node_is_tcon(struct device_node *node)
> +{
> + return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon");
> +}
> +
>  static int compare_of(struct device *dev, void *data)
>  {
>   DRM_DEBUG_DRIVER("Comparing of node %s with %s\n",
> @@ -270,6 +275,25 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>   continue;
>   }
>  
> + /*
> +  * If the node is our TCON, the first port is used for our
> +  * panel, and will not be part of the
> +  * component framework.
> +  */
> + if (sun4i_drv_node_is_tcon(node)) {
> + struct of_endpoint endpoint;
> +
> + if (of_graph_parse_endpoint(ep, )) {
> + DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
> + continue;
> + }
> +
> + if (!endpoint.id) {
> + DRM_DEBUG_DRIVER("Endpoint is our panel... 
> skipping\n");
> + continue;
> + }
> + }
> +
>   /* Walk down our tree */
>   count += sun4i_drv_add_endpoints(dev, match, remote);
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> new file mode 100644
> index ..ab6494818050
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -0,0 +1,250 @@
> +/*
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * Maxime Ripard <maxime.rip...@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_drv.h"
> +#include "sun4i_tcon.h"
> +
> +struct sun4i_rgb {
> + struct drm_connectorconnector;
> + struct drm_encoder  encoder;
> +
> + struct sun4i_drv*drv;
> +};
> +
> +static inline struct sun4i_rgb *
> +drm_connector_to_sun4i_rgb(struct drm_connector *connector)
> +{
> + return container_of(connector, struct sun4i_rgb,
> + connector);
> +}
> +
> +static inline struct sun4i_rgb *
> +drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
> +{
> + return container_of(encoder, struct sun4i_rgb,
> + encoder);
> +}
> +
> +static int sun4i_rgb_get_modes(struct drm_connector *connector)
> +{
> + struct sun4i_rgb *rgb =
> + 

[linux-sunxi] Re: [PATCH v4 05/11] drm: Add Allwinner A10 Display Engine support

2016-04-26 Thread Boris Brezillon
Hi Maxime,

On Mon, 25 Apr 2016 15:22:46 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> The Allwinner A10 and subsequent SoCs share the same display pipeline, with
> variations in the number of controllers (1 or 2), or the presence or not of
> some output (HDMI, TV, VGA) or not.
> 
> Add a driver with a limited set of features for now, and we will hopefully
> support all of them eventually
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Just 2 comments below. Once addressed you can add my

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> ---

[...]

> +
> +static int sun4i_drv_connector_plug_all(struct drm_device *drm)
> +{
> + struct drm_connector *connector, *failed;
> + int ret;
> +
> + mutex_lock(>mode_config.mutex);
> + list_for_each_entry(connector, >mode_config.connector_list, head) {
> + ret = drm_connector_register(connector);
> + if (ret) {
> + failed = connector;
> + goto err;
> + }
> + }
> + mutex_unlock(>mode_config.mutex);
> + return 0;
> +
> +err:
> + list_for_each_entry(connector, >mode_config.connector_list, head) {
> + if (failed == connector)
> + break;
> +
> + drm_connector_unregister(connector);
> + }
> + mutex_unlock(>mode_config.mutex);
> +
> + return ret;
> +}

You can use the generic drm_connector_register_all() to do that.

[...]

> +
> +static void sun4i_drv_unbind(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> +

And you probably miss a call to drm_connector_unregister_all() here.

> + drm_dev_unregister(drm);
> + drm_kms_helper_poll_fini(drm);
> + sun4i_framebuffer_free(drm);
> + drm_vblank_cleanup(drm);
> + drm_dev_unref(drm);
> +}


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot

2016-04-25 Thread Boris Brezillon
On Mon, 25 Apr 2016 13:36:46 -0400
Tom Rini <tr...@konsulko.com> wrote:

> On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> 
> > Hi Scott,
> > 
> > I've recently contributed a lot of MTD/NAND related patches (and intend
> > to continue doing so). Some of them are transversal changes touching the
> > MTD and NAND framework internals, which implies patching all NAND
> > drivers along with the core changes.
> > 
> > All those changes are required to properly handle modern NANDs (MLC/TLC
> > NANDs), and I need them to add proper NAND support to the sunxi
> > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > 
> > So my question is, how should I port those changes to U-Boot? I see
> > that your doing "synchronization commits", but in my case this mean
> > including a bunch of driver specific changes into this "sync commit".
> > 
> > I think it's also worth mentioning that I plan to heavily rework the
> > Linux NAND framework to improve NAND performances on modern NAND
> > controllers and clarify the NAND chip / NAND controller concepts, and
> > other people are also working on merging the BBT code of the NAND and
> > OneNAND framework. Which unfortunately means that we're not done porting
> > invasive changes to U-Boot :-/.
> > 
> > Any advice is welcome.  
> 
> I suppose my first suggestion would be to sync the kernel back into
> U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> be too hard to pick a window to grab the current kernel release and
> bring it over.  I think the more stuff we let build up prior to syncing
> the harder it will be.
> 

Okay, so this means I should be the one back-porting Linux changes into
U-Boot? I was planning on porting my current work on the sunxi NAND
driver (including all the core dependencies) and submitting it to
U-Boot, but honestly, I don't see how I can keep things in sync in the
long run. From my experience, porting things to U-Boot is never as
easy at it seems, and I don't think I'll have the time to maintain that
by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
Can I expect some help from your side?


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Porting Linux's MTD/NAND changes into U-Boot

2016-04-25 Thread Boris Brezillon
Hi Scott,

I've recently contributed a lot of MTD/NAND related patches (and intend
to continue doing so). Some of them are transversal changes touching the
MTD and NAND framework internals, which implies patching all NAND
drivers along with the core changes.

All those changes are required to properly handle modern NANDs (MLC/TLC
NANDs), and I need them to add proper NAND support to the sunxi
platform (and more particularly to the C.H.I.P from NextThing Co.).

So my question is, how should I port those changes to U-Boot? I see
that your doing "synchronization commits", but in my case this mean
including a bunch of driver specific changes into this "sync commit".

I think it's also worth mentioning that I plan to heavily rework the
Linux NAND framework to improve NAND performances on modern NAND
controllers and clarify the NAND chip / NAND controller concepts, and
other people are also working on merging the BBT code of the NAND and
OneNAND framework. Which unfortunately means that we're not done porting
invasive changes to U-Boot :-/.

Any advice is welcome.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   4   5   6   7   8   9   10   >