| Message ID | 20160809171518.22690-4-kbeldan@baylibre.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > This adds DT support for the NAND connected to the SoC AEMIF. > The parameters (timings, ecc) are the same as what the board ships with > (default AEMIF timings, 1bit ECC) and improvements will be handled in > due course. I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that. If driver is broken for 4-bit ECC, please fix that up first. > This passed elementary tests hashing a 20MB file on top of ubifs on my > LCDK. > > Signed-off-by: Karl Beldan <kbeldan@baylibre.com> Thanks, Sekhar
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: > On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > > This adds DT support for the NAND connected to the SoC AEMIF. > > The parameters (timings, ecc) are the same as what the board ships with > > (default AEMIF timings, 1bit ECC) and improvements will be handled in > > due course. > > I disagree that we need to be compatible to the software that ships with > the board. Thats software was last updated 3 years ago. Instead I would > concern with what the hardware supports. So, if the hardware can support > 4-bit ECC, I would use that. > I am not saying we _need_ to be compatible. > If driver is broken for 4-bit ECC, please fix that up first. > Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies. I took note that you are likely to not apply without the ECC fix. Karl > > This passed elementary tests hashing a 20MB file on top of ubifs on my > > LCDK. > > > > Signed-off-by: Karl Beldan <kbeldan@baylibre.com> > > Thanks, > Sekhar
On Tue, Aug 09, 2016 at 05:15:17PM +0000, Karl Beldan wrote: > This adds DT support for the NAND connected to the SoC AEMIF. > The parameters (timings, ecc) are the same as what the board ships with > (default AEMIF timings, 1bit ECC) and improvements will be handled in > due course. > This passed elementary tests hashing a 20MB file on top of ubifs on my > LCDK. > > Signed-off-by: Karl Beldan <kbeldan@baylibre.com> > --- > arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 108 insertions(+) > > diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts > index dbcca0b..033380b 100644 > --- a/arch/arm/boot/dts/da850-lcdk.dts > +++ b/arch/arm/boot/dts/da850-lcdk.dts > @@ -27,6 +27,27 @@ > > &pmx_core { > status = "okay"; > + > + nand_pins: nand_pins { > + pinctrl-single,bits = < > + /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[3] */ > + 0x1c 0x10110010 0xf0ff00f0 > + /* > + * EMA_D[0], EMA_D[1], EMA_D[2], > + * EMA_D[3], EMA_D[4], EMA_D[5], > + * EMA_D[6], EMA_D[7] > + */ > + 0x24 0x11111111 0xffffffff > + /* > + * EMA_D[8], EMA_D[9], EMA_D[10], > + * EMA_D[11], EMA_D[12], EMA_D[13], > + * EMA_D[14], EMA_D[15] > + */ > + 0x20 0x11111111 0xffffffff > + /* EMA_A[1], EMA_A[2] */ > + 0x30 0x01100000 0x0ff00000 > + >; > + }; > }; > > &serial2 { > @@ -68,3 +89,90 @@ > cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>; > status = "okay"; > }; > + > +&aemif { > + pinctrl-names = "default"; > + pinctrl-0 = <&nand_pins>; > + status = "ok"; > + cs2 { Typo, should be cs3. Karl > + #address-cells = <2>; > + #size-cells = <1>; > + clock-ranges; > + ranges; > + > + ti,cs-chipselect = <2>; > + > + nand@2000000,0 { > + compatible = "ti,davinci-nand"; > + #address-cells = <1>; > + #size-cells = <1>; > + reg = <0 0x02000000 0x02000000 > + 1 0x00000000 0x00008000>; > + > + ti,davinci-chipselect = <1>; > + ti,davinci-mask-ale = <0>; > + ti,davinci-mask-cle = <0>; > + ti,davinci-mask-chipsel = <0>; > + > + /* > + * nand_ecc_strength_good will emit a warning > + * but the LCDK ships with these settings [1]. > + * Also HW 4bits ECC with 16bits NAND seems to > + * require some attention. > + * > + * ATM nand_davinci_probe handling of nand-ecc-* > + * is broken, e.g. > + * chip.ecc.strength = pdata->ecc_bits occurs after > + * scan_ident(), otherwise I would have used: > + * nand-ecc-mode = "hw"; > + * nand-ecc-strength = <1>; > + * nand-ecc-step-size = <512>; > + */ > + ti,davinci-ecc-mode = "hw"; > + ti,davinci-ecc-bits = <1>; > + > + nand-bus-width= <16>; > + nand-on-flash-bbt; > + > + /* > + * LCDK original partitions: > + * 0x000000000000-0x000000020000 : "u-boot env" > + * 0x000000020000-0x0000000a0000 : "u-boot" > + * 0x0000000a0000-0x0000002a0000 : "kernel" > + * 0x0000002a0000-0x000020000000 : "filesystem" > + * > + * The 1st NAND block being guaranted to be valid w/o ECC (> 1k cycles), > + * it makes a perfect candidate as an SPL for the BootROM to jump to. > + * However the OMAP-L132/L138 Bootloader doc SPRAB41E reads: > + * "To boot from NAND Flash, the AIS should be written to NAND block 1 > + * (NAND block 0 is not used by default)", which matches the LCDK > + * original partitioning. > + * Also, the LCDK ships with only the u-boot partition provisioned and > + * boots on it in its default configuration while using the MMC for the > + * kernel and rootfs, so preserve that one as is for now. > + * [1]: Ensuring for example that U-Boot LCDK SPL can handle it properly > + * and a proper boot chain ROM->SPL->U-Boot->Linux wrt ECC, would allow > + * for a better partitioning. > + */ > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "u-boot env"; > + reg = <0 0x020000>; > + }; > + partition@0x020000 { > + /* The LCDK defaults to booting from this partition */ > + label = "u-boot"; > + reg = <0x020000 0x080000>; > + }; > + partition@0x0a0000 { > + label = "space"; > + reg = <0x0a0000 0>; > + }; > + }; > + }; > + }; > +}; > -- > 2.9.2 >
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote: > On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: >> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: >>> This adds DT support for the NAND connected to the SoC AEMIF. >>> The parameters (timings, ecc) are the same as what the board ships with >>> (default AEMIF timings, 1bit ECC) and improvements will be handled in >>> due course. >> >> I disagree that we need to be compatible to the software that ships with >> the board. Thats software was last updated 3 years ago. Instead I would >> concern with what the hardware supports. So, if the hardware can support >> 4-bit ECC, I would use that. >> > I am not saying we _need_ to be compatible. Alright then, please drop references to what software the board ships with in the commit message and in the patch itself. > >> If driver is broken for 4-bit ECC, please fix that up first. >> > Since this issue is completely separate from my DT improvements > I'll stick to resubmitting the series, applying my LCDK changes to the > EVM too, besides you'll be able to compare the behavior without ECC > discrepancies. > I took note that you are likely to not apply without the ECC fix. Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after. Regards, Sekhar
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote: > On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote: > > On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: > >> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > >>> This adds DT support for the NAND connected to the SoC AEMIF. > >>> The parameters (timings, ecc) are the same as what the board ships with > >>> (default AEMIF timings, 1bit ECC) and improvements will be handled in > >>> due course. > >> > >> I disagree that we need to be compatible to the software that ships with > >> the board. Thats software was last updated 3 years ago. Instead I would > >> concern with what the hardware supports. So, if the hardware can support > >> 4-bit ECC, I would use that. > >> > > I am not saying we _need_ to be compatible. > > Alright then, please drop references to what software the board ships > with in the commit message and in the patch itself. > I hadn't seen this comment before sending v2. > > > >> If driver is broken for 4-bit ECC, please fix that up first. > >> > > Since this issue is completely separate from my DT improvements > > I'll stick to resubmitting the series, applying my LCDK changes to the > > EVM too, besides you'll be able to compare the behavior without ECC > > discrepancies. > > I took note that you are likely to not apply without the ECC fix. > > Yeah, I would not like to apply with 1-bit ECC now and then change to > 4-bit ECC soon after. > Both mityomapl138 from mainline and hawkboard from TI's BSP release include the comment: - "4 bit mode is not supported with 16 bit NAND" It is not clear whether they imply that the HW has issues or if it's SW only, but 4-bits ECC is a different matter and I hope you'll integrate the current changes prior to tackling it. Karl
On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote: > On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote: >> On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote: >>> On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: >>>> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: >>>>> This adds DT support for the NAND connected to the SoC AEMIF. >>>>> The parameters (timings, ecc) are the same as what the board ships with >>>>> (default AEMIF timings, 1bit ECC) and improvements will be handled in >>>>> due course. >>>> >>>> I disagree that we need to be compatible to the software that ships with >>>> the board. Thats software was last updated 3 years ago. Instead I would >>>> concern with what the hardware supports. So, if the hardware can support >>>> 4-bit ECC, I would use that. >>>> >>> I am not saying we _need_ to be compatible. >> >> Alright then, please drop references to what software the board ships >> with in the commit message and in the patch itself. >> > > I hadn't seen this comment before sending v2. > >>> >>>> If driver is broken for 4-bit ECC, please fix that up first. >>>> >>> Since this issue is completely separate from my DT improvements >>> I'll stick to resubmitting the series, applying my LCDK changes to the >>> EVM too, besides you'll be able to compare the behavior without ECC >>> discrepancies. >>> I took note that you are likely to not apply without the ECC fix. >> >> Yeah, I would not like to apply with 1-bit ECC now and then change to >> 4-bit ECC soon after. >> > > Both mityomapl138 from mainline and hawkboard from TI's BSP release > include the comment: > - "4 bit mode is not supported with 16 bit NAND" > It is not clear whether they imply that the HW has issues or if it's SW At least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed to work for 16-bit NAND. I could not find any errata related to this in the errata document. > only, but 4-bits ECC is a different matter and I hope you'll integrate > the current changes prior to tackling it. Lets apply everything together. This is a new feature, not a bug fix. There is no need to rush it. Also, for the NAND part on LCDK, per the micron datasheet, minimum of 4-bit ECC is needed. I will take a look at other patches in this series. Regards, Sekhar
On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote: > On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote: > > On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote: > >> On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote: > >>> On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: > >>>> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > >>>>> This adds DT support for the NAND connected to the SoC AEMIF. > >>>>> The parameters (timings, ecc) are the same as what the board ships with > >>>>> (default AEMIF timings, 1bit ECC) and improvements will be handled in > >>>>> due course. > >>>> > >>>> I disagree that we need to be compatible to the software that ships with > >>>> the board. Thats software was last updated 3 years ago. Instead I would > >>>> concern with what the hardware supports. So, if the hardware can support > >>>> 4-bit ECC, I would use that. > >>>> > >>> I am not saying we _need_ to be compatible. > >> > >> Alright then, please drop references to what software the board ships > >> with in the commit message and in the patch itself. > >> > > > > I hadn't seen this comment before sending v2. > > > >>> > >>>> If driver is broken for 4-bit ECC, please fix that up first. > >>>> > >>> Since this issue is completely separate from my DT improvements > >>> I'll stick to resubmitting the series, applying my LCDK changes to the > >>> EVM too, besides you'll be able to compare the behavior without ECC > >>> discrepancies. > >>> I took note that you are likely to not apply without the ECC fix. > >> > >> Yeah, I would not like to apply with 1-bit ECC now and then change to > >> 4-bit ECC soon after. > >> > > > > Both mityomapl138 from mainline and hawkboard from TI's BSP release > > include the comment: > > - "4 bit mode is not supported with 16 bit NAND" > > It is not clear whether they imply that the HW has issues or if it's SW > > At least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND > Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed > to work for 16-bit NAND. I could not find any errata related to this in > the errata document. > > > only, but 4-bits ECC is a different matter and I hope you'll integrate > > the current changes prior to tackling it. > > Lets apply everything together. This is a new feature, not a bug fix. > There is no need to rush it. Also, for the NAND part on LCDK, per the > micron datasheet, minimum of 4-bit ECC is needed. > FYI my patches are related to a small contracting work spanning 20 days amounting to 15 real days (from scratch). ATM my SoW not only doesn't include this 'new feature' but excludes it. So I cannot promise I'll look into it, though it shouldn't be too big a thing. It seemed clear that you wanted to squeeze it with the rest, but after setting things up for the EVM and observing mainline was broken with 4bits ECC on an 8bits NAND I thought it was impossible nobody hadn't noticed it .. so I dug in the mail archive, only to find there had already been some alerts raised some months ago on the list, so I picked up my next item. > I will take a look at other patches in this series. > Ok, thanks. Rgds, Karl
On Tue, Aug 16, 2016 at 11:20:29PM +0000, Karl Beldan wrote: > On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote: > > On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote: > > > On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote: > > >> On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote: > > >>> On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: > > >>>> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > > >>>>> This adds DT support for the NAND connected to the SoC AEMIF. > > >>>>> The parameters (timings, ecc) are the same as what the board ships with > > >>>>> (default AEMIF timings, 1bit ECC) and improvements will be handled in > > >>>>> due course. > > >>>> > > >>>> I disagree that we need to be compatible to the software that ships with > > >>>> the board. Thats software was last updated 3 years ago. Instead I would > > >>>> concern with what the hardware supports. So, if the hardware can support > > >>>> 4-bit ECC, I would use that. > > >>>> > > >>> I am not saying we _need_ to be compatible. > > >> > > >> Alright then, please drop references to what software the board ships > > >> with in the commit message and in the patch itself. > > >> > > > > > > I hadn't seen this comment before sending v2. > > > > > >>> > > >>>> If driver is broken for 4-bit ECC, please fix that up first. > > >>>> > > >>> Since this issue is completely separate from my DT improvements > > >>> I'll stick to resubmitting the series, applying my LCDK changes to the > > >>> EVM too, besides you'll be able to compare the behavior without ECC > > >>> discrepancies. > > >>> I took note that you are likely to not apply without the ECC fix. > > >> > > >> Yeah, I would not like to apply with 1-bit ECC now and then change to > > >> 4-bit ECC soon after. > > >> > > > > > > Both mityomapl138 from mainline and hawkboard from TI's BSP release > > > include the comment: > > > - "4 bit mode is not supported with 16 bit NAND" > > > It is not clear whether they imply that the HW has issues or if it's SW > > > > At least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND > > Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed > > to work for 16-bit NAND. I could not find any errata related to this in > > the errata document. > > > > > only, but 4-bits ECC is a different matter and I hope you'll integrate > > > the current changes prior to tackling it. > > > > Lets apply everything together. This is a new feature, not a bug fix. > > There is no need to rush it. Also, for the NAND part on LCDK, per the > > micron datasheet, minimum of 4-bit ECC is needed. > > > > FYI my patches are related to a small contracting work spanning 20 days > amounting to 15 real days (from scratch). ATM my SoW not only doesn't > include this 'new feature' but excludes it. So I cannot promise I'll > look into it, though it shouldn't be too big a thing. I took a look at it yesterday, cf. https://lkml.org/lkml/2016/8/29/71 Karl > It seemed clear that you wanted to squeeze it with the rest, but after > setting things up for the EVM and observing mainline was broken with > 4bits ECC on an 8bits NAND I thought it was impossible nobody hadn't > noticed it .. so I dug in the mail archive, only to find there had > already been some alerts raised some months ago on the list, so I picked > up my next item. > > > I will take a look at other patches in this series. > > > > Ok, thanks. > > Rgds, > Karl
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts index dbcca0b..033380b 100644 --- a/arch/arm/boot/dts/da850-lcdk.dts +++ b/arch/arm/boot/dts/da850-lcdk.dts @@ -27,6 +27,27 @@ &pmx_core { status = "okay"; + + nand_pins: nand_pins { + pinctrl-single,bits = < + /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[3] */ + 0x1c 0x10110010 0xf0ff00f0 + /* + * EMA_D[0], EMA_D[1], EMA_D[2], + * EMA_D[3], EMA_D[4], EMA_D[5], + * EMA_D[6], EMA_D[7] + */ + 0x24 0x11111111 0xffffffff + /* + * EMA_D[8], EMA_D[9], EMA_D[10], + * EMA_D[11], EMA_D[12], EMA_D[13], + * EMA_D[14], EMA_D[15] + */ + 0x20 0x11111111 0xffffffff + /* EMA_A[1], EMA_A[2] */ + 0x30 0x01100000 0x0ff00000 + >; + }; }; &serial2 { @@ -68,3 +89,90 @@ cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>; status = "okay"; }; + +&aemif { + pinctrl-names = "default"; + pinctrl-0 = <&nand_pins>; + status = "ok"; + cs2 { + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + ti,cs-chipselect = <2>; + + nand@2000000,0 { + compatible = "ti,davinci-nand"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0x02000000 0x02000000 + 1 0x00000000 0x00008000>; + + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + + /* + * nand_ecc_strength_good will emit a warning + * but the LCDK ships with these settings [1]. + * Also HW 4bits ECC with 16bits NAND seems to + * require some attention. + * + * ATM nand_davinci_probe handling of nand-ecc-* + * is broken, e.g. + * chip.ecc.strength = pdata->ecc_bits occurs after + * scan_ident(), otherwise I would have used: + * nand-ecc-mode = "hw"; + * nand-ecc-strength = <1>; + * nand-ecc-step-size = <512>; + */ + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <1>; + + nand-bus-width= <16>; + nand-on-flash-bbt; + + /* + * LCDK original partitions: + * 0x000000000000-0x000000020000 : "u-boot env" + * 0x000000020000-0x0000000a0000 : "u-boot" + * 0x0000000a0000-0x0000002a0000 : "kernel" + * 0x0000002a0000-0x000020000000 : "filesystem" + * + * The 1st NAND block being guaranted to be valid w/o ECC (> 1k cycles), + * it makes a perfect candidate as an SPL for the BootROM to jump to. + * However the OMAP-L132/L138 Bootloader doc SPRAB41E reads: + * "To boot from NAND Flash, the AIS should be written to NAND block 1 + * (NAND block 0 is not used by default)", which matches the LCDK + * original partitioning. + * Also, the LCDK ships with only the u-boot partition provisioned and + * boots on it in its default configuration while using the MMC for the + * kernel and rootfs, so preserve that one as is for now. + * [1]: Ensuring for example that U-Boot LCDK SPL can handle it properly + * and a proper boot chain ROM->SPL->U-Boot->Linux wrt ECC, would allow + * for a better partitioning. + */ + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "u-boot env"; + reg = <0 0x020000>; + }; + partition@0x020000 { + /* The LCDK defaults to booting from this partition */ + label = "u-boot"; + reg = <0x020000 0x080000>; + }; + partition@0x0a0000 { + label = "space"; + reg = <0x0a0000 0>; + }; + }; + }; + }; +};
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course. This passed elementary tests hashing a 20MB file on top of ubifs on my LCDK. Signed-off-by: Karl Beldan <kbeldan@baylibre.com> --- arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+)