Re: [linux-sunxi] Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Priit Laes]

On Wed, 2016-06-01 at 20:00 +0200, Maxime Ripard wrote:
> Hi,
> 
> On Mon, May 30, 2016 at 04:50:16PM +0100, Mark Brown wrote:
> > 
> > On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
> > > 
> > > On 30 May 2016 at 17:03, Mark Brown  wrote:
> > > 
> > > > 
> > > > I really don't think it's worth caring too much about cases
> > > > where the
> > > > DMA driver hasn't been compiled in, it's not like SPI is the
> > > > only thing
> > > 
> > > It's what the driver did to start with and it was requested to
> > > fall
> > > back to non-DMA in the case DMA is not available.
> > Why?  I really can't see any sensible use case for this that
> > doesn't
> > have a better solution available.
> SPI works just fine without DMA, which might just be considered an
> (optional) optimisation.
> 
> We've been using it without DMA for years now, and it was working
> just
> fine, and it will work even better with the other patches in this
> serie. There's no reason to add a hard dependency on something that
> we
> don't really need.
> 

Actually it non-DMA case works fine if you don't need SPI transfers
larger than SUN4I_FIFO_DEPTH - 1, which is 63 bytes.

This was addressed by this patch, but was never applied:
http://permalink.gmane.org/gmane.linux.kernel.spi.devel/18950

-- 
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] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Julian Calaby]

Hi Luo yi,

On Thu, Jun 2, 2016 at 12:36 PM,   wrote:
> From: Luo Yi 
>
> Add support for the Bananapi M1 Plus A20 development board from
> sinovoip.com.cn . This board is nearly a clone of the Lemaker's
> Bananapro, but differ with the wlan chipset connection and i2s pinout.
> And I also enable the integrated audio codec on default.

No signed-off-by.

> ---
>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 72 
> 
>  1 file changed, 72 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> new file mode 100644
> index 000..6fd55d7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright 2016 Luo Yi 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun7i-a20-bananapro.dts"
> +
> +/ {
> +   model = "Banana Pi BPI-M1-Plus";
> +   compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
> +};
> +
> +

Extra line.

> + {
> +   status = "okay";
> +};

Does anyone know if this should be enabled on the bananapro too?

> +
> + {
> +   enable-sdio-wakeup;
> +
> +   brcmf: bcrmf@1 {
> +   reg = <1>;
> +   compatible = "brcm,bcm4329-fmac";
> +   interrupt-parent = <>;
> +   interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
> +   interrupt-names = "host-wake";
> +   };
> +

Extra line.

> +};
> +
> +_pins_a {
> +/* AP6210 requires pull-up */

Should this be indented the same as the following line?

> +   allwinner,pull = ;
> +};
> +

Extra line.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
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] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[luoyi . ly]

From: Luo Yi 

Add support for the Bananapi M1 Plus A20 development board from
sinovoip.com.cn . This board is nearly a clone of the Lemaker's
Bananapro, but differ with the wlan chipset connection and i2s pinout.
And I also enable the integrated audio codec on default.
---
 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 72 
 1 file changed, 72 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
new file mode 100644
index 000..6fd55d7
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2016 Luo Yi 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun7i-a20-bananapro.dts"
+
+/ {
+   model = "Banana Pi BPI-M1-Plus";
+   compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
+};
+
+
+ {
+   status = "okay";
+};
+
+ {
+   enable-sdio-wakeup;
+
+   brcmf: bcrmf@1 {
+   reg = <1>;
+   compatible = "brcm,bcm4329-fmac";
+   interrupt-parent = <>;
+   interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>; 
+   interrupt-names = "host-wake";
+   };
+
+};
+
+_pins_a {
+/* AP6210 requires pull-up */
+   allwinner,pull = ;
+};
+
-- 
2.8.3

-- 
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] Re: random decryption errors with sun4i-ss on dm-crypt

[Timo S.]

Short update:

Corentin's fix (crypto: sun4i-ss - Replace spinlock_bh by
spin_lock_irq{save|restore}) finally made it into the stable/longterm
updates: Greg has just released the versions 4.4.12, 4.5.6 and 4.6.1 -
all of which contain the patch.

Regards,

Timo

On Wed, Apr 20, 2016 at 9:27 AM, LABBE Corentin
 wrote:
> On Tue, Apr 19, 2016 at 08:29:23AM -0700, txsan...@gmail.com wrote:
>> Still nothing :( it seems i can convert my encrypted storage back to XTS, as 
>> i've only converted it to CBC for the hw encryption.
>>
>
> I hàve sent the patch (https://lkml.org/lkml/2016/3/23/302) solving this 
> issue, but it is not present in any tree.
> Anywày, XTS is the recommended wày for disk encryption and it have nearly the 
> same speed than CBC with hw.
>
> Regards
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/linux-sunxi/InsDjSm3J6A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 1/5] spi: sunxi: fix transfer timeout

[Maxime Ripard]

Hi Mark,

On Mon, May 30, 2016 at 12:23:50PM +0100, Mark Brown wrote:
> On Fri, May 27, 2016 at 03:10:11PM +1000, Julian Calaby wrote:
> > On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek  wrote:
> 
> > >> Also, should the changes for the drivers be in two separate patches also?
> 
> > > That's basically the same driver with different constants so I guess not.
> 
> > Fair enough, I withdraw my comment then.
> 
> If it's the same driver with different constants it should really
> actually be the same driver - I did ask this when the drivers were
> originally merged...

I think we already had this discussion a few times :)

The thing is that the SPI framework now deals pretty well with the SPI
controllers, and you basically only have the probe function and how to
start a transfer. Which is nice.

However, the sun4i and sun6i SPI controllers have very significant
register layout differences: the registers offset are different, some
registers in the sun4i have been split in several in the sun6i. So
while I concur that they look alike, merging the two in a single
driver would complicate a lot the code, while we would not be able to
share most of the code, so I am really not sure it's worth it.

Where the issue really lies is that they've been both written at the
same time, and share the same flaws, especially in their probe
method. But that's not really related to the controller itself, but
more because the code has been close to copy/pasted.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 3/5] spi: sunxi: expose maximum transfer size limit

[Maxime Ripard]

On Mon, May 30, 2016 at 10:57:10AM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 30 May 2016 at 10:37, Maxime Ripard  
> wrote:
> > On Thu, May 26, 2016 at 07:25:24PM -, Michal Suchanek wrote:
> >> The sun4i spi hardware can trasfer at most 63 bytes of data without DMA
> >> support so report the limitation. Same on sun6i.
> >
> > Is it? Is there timeouts on the A31 and later SoCs?
> >
> 
> I have no sun6i hardware to test with.
> 
> This is an advisory limit you can query and it better be smaller
> rather than unreliable. The hard limit in the driver is still
> SUN6I_FIFO_DEPTH (which is 128 bytes on sun6i).
> 
> You can test his without any actual SPI device. Unused pins you can
> multiplex as SPI suffice.

Ok, for the time being:

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Maxime Ripard]

Hi,

On Mon, May 30, 2016 at 04:50:16PM +0100, Mark Brown wrote:
> On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
> > On 30 May 2016 at 17:03, Mark Brown  wrote:
> 
> > > I really don't think it's worth caring too much about cases where the
> > > DMA driver hasn't been compiled in, it's not like SPI is the only thing
> 
> > It's what the driver did to start with and it was requested to fall
> > back to non-DMA in the case DMA is not available.
> 
> Why?  I really can't see any sensible use case for this that doesn't
> have a better solution available.

SPI works just fine without DMA, which might just be considered an
(optional) optimisation.

We've been using it without DMA for years now, and it was working just
fine, and it will work even better with the other patches in this
serie. There's no reason to add a hard dependency on something that we
don't really need.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Maxime Ripard]

Hi,

On Wed, Jun 01, 2016 at 10:40:18AM +0800, luoyi wrote:
> This is the new version of the patch.  and I think maybe every board
> should have their own dtb files. and we can you some cpp  macro tricks
> to merge their coressponding dts file.

Please submit it as a new patch with send-email, with the version
(using the -v option) and a log of your changes.

> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e06a5ab..fde407f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -685,6 +685,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>  sun6i-a31s-yones-toptech-bs1078-v2.dtb
>  dtb-$(CONFIG_MACH_SUN7I) += \
>  sun7i-a20-bananapi.dtb \
> +sun7i-a20-bananapi-m1-plus.dtb \
>  sun7i-a20-bananapro.dtb \
>  sun7i-a20-cubieboard2.dtb \
>  sun7i-a20-cubietruck.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> new file mode 100644
> index 000..548ed31
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright 2016 Luo Yi 
> + *
> + * Thanks to the original work by Hans de Goede 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +#include 
> +#include 
> +
> +/ {
> +model = "Banana Pi BPI-M1-Plus";
> +compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
> +
> +aliases {
> +serial0 = 
> +};
> +
> +chosen {
> +stdout-path = "serial0:115200n8";
> +};
> +
> +leds {
> +compatible = "gpio-leds";
> +pinctrl-names = "default";
> +pinctrl-0 = <_pins_bananapi>;
> +
> +green {
> +label = "bananapi:green:usr";
> +gpios = < 7 24 GPIO_ACTIVE_HIGH>;
> +};
> +
> +red {
> +label = "bananapi:red:usr";
> +gpios = < 7 25 GPIO_ACTIVE_HIGH>;
> +linux,default-trigger = "default-on";
> +};
> +
> +};
> +
> +mmc3_pwrseq: mmc3_pwrseq {
> +compatible = "mmc-pwrseq-simple";
> +pinctrl-names = "default";
> +pinctrl-0 = <_pwrseq_pin_bananapim1plus>;
> +reset-gpios = < 7 22 GPIO_ACTIVE_LOW>; /* PH22 WL-PMU-EN */
> +};
> +
> +reg_gmac_3v3: gmac-3v3 {
> +compatible = "regulator-fixed";
> +pinctrl-names = "default";
> +pinctrl-0 = <_power_pin_bananapi>;
> +regulator-name = "gmac-3v3";
> +regulator-min-microvolt = <330>;
> +regulator-max-microvolt = <330>;
> +startup-delay-us = <10>;
> +enable-active-high;
> +gpio = < 7 23 GPIO_ACTIVE_HIGH>;
> +};
> +
> +};
> +
> + {
> +status = "okay";
> +};
> +
> + {
> +status = "okay";
> +};
> +
> + {
> +status = "okay";
> +};
> +
> + {
> +status = "okay";
> +};
> +
> + {
> +pinctrl-names = "default";

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

[Maxime Ripard]

Hi,

On Wed, Jun 01, 2016 at 03:35:07PM +0300, Siarhei Siamashka wrote:
> On Wed,  1 Jun 2016 13:23:24 +0200
> Boris Brezillon  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 
> > Acked-by: Hans de Goede 
> 
> 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.

So you want to favour a solution that hardcodes the NAND configuration
over a solution that runtime-detects what it needs?

I think we are aiming for two very different use-cases: we want to
have everything working ahead of time on various NAND chips during
production, you want to have the end-users being able to reflash
something after the production.

Boris' solution address both use-cases, yours address only the latter.

> 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.

I know you like it a lot, but I don't see how
u-boot-sunxi-with-spl.bin is relevant here. It's an image that has
always been built for the MMC.

We are talking about the NAND here, that will use a different image
format anyway to deal with the randomizer and the ECC, that will have
to use redundancy for the SPL, U-Boot and probably environment images,
that will have to be padded with random data, and doesn't want to
waste the useless (on NAND) padding that is used in that image.

> 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

On all the sunxi boards that have NAND at least.

> 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 :-)

Good thing we are talking about NAND support and not some bloat then :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.


signature.asc
Description: PGP signature

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

[Boris Brezillon]

On Wed, 1 Jun 2016 15:35:07 +0300
Siarhei Siamashka  wrote:

> On Wed,  1 Jun 2016 13:23:24 +0200
> Boris Brezillon  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 
> > Acked-by: Hans de Goede   
> 
> 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

[Boris Brezillon]

On Wed, 1 Jun 2016 14:43:22 +0200
Bernhard Nortmann  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 
> > ---
> >   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

[Boris Brezillon]

On Wed, 1 Jun 2016 14:41:36 +0300
Siarhei Siamashka  wrote:

> On Mon, 30 May 2016 19:02:13 +0200
> Boris Brezillon  wrote:
> 
> > On Mon, 30 May 2016 19:46:17 +0300
> > Siarhei Siamashka  wrote:
> >   
> > > On Mon, 30 May 2016 17:24:16 +0200
> > > Boris Brezillon  wrote:
> > > 
> > > > Hi Hans,
> > > > 
> > > > On Mon, 30 May 2016 17:12:53 +0200
> > > > Boris Brezillon  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.  
> 
> Ultimately we want to have a complete solution. So that the NAND flash
> can be programmed both at the production line and by the end users of
> the devices. How many more tools do we need to achieve this goal?

Not sure what you mean by that. So you want a single sunxi-fel tool
able that would be able to do everything from flash media detection to
image preparation and flashing.

That's a nice objective, but let's stay realist, this tool does not
exist yet, and I think you underestimate the amount of work needed to
correctly implement NAND flash detection.

If we really are ready to do that at some point, then we'll still be
able to expose the nand-image-builder functionalities as a lib and link
the sunxi-fel tool with it.

> 
> > Now, if there's a way to export NAND memory organization through the
> > SPL header, that's even better,  
> 
> Currently the U-Boot build 

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

[Bernhard Nortmann]

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 
---
  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.

Regards, B. Nortmann

--
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

[Siarhei Siamashka]

On Wed,  1 Jun 2016 13:23:24 +0200
Boris Brezillon  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 
> Acked-by: Hans de Goede 

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 :-)

[1] http://lists.denx.de/pipermail/u-boot/2015-September/226963.html

-- 
Best regards,
Siarhei Siamashka

-- 
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

[Siarhei Siamashka]

On Mon, 30 May 2016 19:02:13 +0200
Boris Brezillon  wrote:

> On Mon, 30 May 2016 19:46:17 +0300
> Siarhei Siamashka  wrote:
> 
> > On Mon, 30 May 2016 17:24:16 +0200
> > Boris Brezillon  wrote:
> >   
> > > Hi Hans,
> > > 
> > > On Mon, 30 May 2016 17:12:53 +0200
> > > Boris Brezillon  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.

Ultimately we want to have a complete solution. So that the NAND flash
can be programmed both at the production line and by the end users of
the devices. How many more tools do we need to achieve this goal?

> Now, if there's a way to export NAND memory organization through the
> SPL header, that's even better,

Currently the U-Boot build system produces the u-boot-sunxi-with-spl.bin
file. This file consists of the SPL part in the beginning and the main
U-Boot binary (in a legacy format now, but maybe moving to FIT later).

The SPL part has the 64 byte header in the beginning (the size can be
increased if necessary):


http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/spl.h

This SPL header can be interpreted as a blank form, which can be
populated with the useful information by the other tools. What we
have right now is that:
* The boot ROM writes the type of the boot device at the offset 0x28
* The sunxi-fel tool writes the "fel_script_address" field when
  doing FEL boot over USB OTG and also overrides the header magic
  to indicate that we are booting from FEL.

Nothing prevents the SPI flash or NAND flash image 

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

[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 
Acked-by: Hans de Goede 
---
 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

[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 
Acked-by: Hans de Goede 
---
 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 

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

[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 
Acked-by: Hans de Goede 
---
 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

[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 
Acked-by: Hans de Goede 
---
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 = nand_max_ecc_strength(conf);
+
+   nand_apply_config(conf);
+
+   /*
+* We 

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

[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 
Acked-by: Hans de Goede 
---
 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

[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 
Acked-by: Hans de Goede 
---
 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

[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 
Acked-by: Hans de Goede 
---
 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 */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   rand_seed = random_seed[page % 128];
+   

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

[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

[Boris Brezillon]

On Fri, 20 May 2016 15:55:51 +0200
Boris Brezillon  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 
> ---
>  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 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 >= 

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

[Bernhard Nortmann]

Am 01.06.2016 um 11:05 schrieb 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 
---
  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))) {


When changing that line, please strip the surplus braces around `eccbytes`.


+   fprintf(stderr,
+   "ECC bytes do not fit in the NAND page, choose a weaker 
ECC\n");
return -EINVAL;
+   }
  
  	return 0;

  }


Apart from the nitpick above
Acked-by: Bernhard Nortmann 

--
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 1/3] nand-image-builder: Fix the copyright header

[Bernhard Nortmann]

Am 01.06.2016 um 11:05 schrieb 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 
---
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


To me that looks much better now. I'd also like to suggest keeping a 
one-line

reference/link to the original kernel source, e.g.

See also: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/bch.c


(or maybe http://lxr.free-electrons.com/source/lib/bch.c instead).

--
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 1/3] nand-image-builder: Fix the copyright header

[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 
---
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 
  *
- * 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 
  *
- * [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

[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 
---
 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()

[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 
---
 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.