Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hi Pekon,
On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
[...]
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
I see and did the GPMC register space became that big to need to map 8KB?
Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:
reg = 0x6e00 0x02d0;
reg = 0x6e00 0x0400;
reg = 0x6e00 0x1000;
in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.
Yes, I agree with you.
I have fixed this in newer version of the patch and will be sending it soon.
But this series will only contain updates for new platforms with addition
of NAND node in DTS, so that this series is not stalled for any reason.
For fixing existing platform/boards DTS I'll send another series soon.
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)
For the ELM module it should be 4KB i.e. 0x1000
cheers,
-roger
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
�{.n�+���+%��lzwm��b�맲��r��zX��j�����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?�)ߢf
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hi Roger,
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
I think that is copy-paste error in documentation.
In the same TRM, you 'll find the correct address offsets for GPMC Registers in
below
*Section: 15.4.7.1 GPMC Register Summary*
Register Starting Offset
End Offset
GPMC_BCH_RESULT4_i0x 0300 + (0x 0010 * i) 0x5000 0300 + (0x
0010 * i)
GPMC_BCH_RESULT5_i0x 0304 + (0x 0010 * i) 0x5000 0304 + (0x
0010 * i)
GPMC_BCH_RESULT6_i0x 0308 + (0x 0010 * i) 0x5000 0308 + (0x
0010 * i)
Where i = 0 to 7 ..
So that makes last address 0x5000_0378 (for GPMC_BCH_RESULT6_7)
As the each register bank (i) is incrementing at 0x10, so last accessible
address is 0x37F.
I have already raised documentation bug for AM335x TRM,
Need to raise the same for DRA7xx TRM.
For the ELM module it should be 4KB i.e. 0x1000
Yes, that is correct. I have fixed that now.
cheers,
-roger
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
On 05/14/2014 11:25 AM, Roger Quadros wrote:
Hi Pekon,
On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
[...]
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
I see and did the GPMC register space became that big to need to map 8KB?
Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:
reg = 0x6e00 0x02d0;
reg = 0x6e00 0x0400;
reg = 0x6e00 0x1000;
in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.
Yes, I agree with you.
I have fixed this in newer version of the patch and will be sending it soon.
But this series will only contain updates for new platforms with addition
of NAND node in DTS, so that this series is not stalled for any reason.
For fixing existing platform/boards DTS I'll send another series soon.
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
Sorry for the noise.
Just figured out that the register space is not numerically arranged in the TRM.
The last register is P GPMC_BCH_RESULT6_i
0x5000 0308 + (0x 0010 * i)
i = 0 to 7
So size should be 0x37C.
cheers,
-roger
For the ELM module it should be 4KB i.e. 0x1000
cheers,
-roger
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
�{.n�+���+%��lzwm��b�맲��r��zX��j�����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?�)ߢf
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
From: Quadros, Roger
[...]
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
Sorry for the noise.
Just figured out that the register space is not numerically arranged in the
TRM.
The last register is P GPMC_BCH_RESULT6_i
0x5000 0308 + (0x 0010 * i)
i = 0 to 7
So size should be 0x37C.
Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
so I aligned the last address to 0x380 boundary. Hope leaving room for
extra 4 bytes (0x380 - 0x37C) will not matter much?
All platforms from OMAP4 onwards share the same version of GPMC engine.
So this remains consistent. Only OMAP3 has older version of GPMC engine
which has register-space till 0x2d0.
cheers,
-roger
with regards, pekon
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
Sorry for the noise.
Just figured out that the register space is not numerically arranged in the
TRM.
The last register is P GPMC_BCH_RESULT6_i
0x5000 0308 + (0x 0010 * i)
i = 0 to 7
So size should be 0x37C.
Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
so I aligned the last address to 0x380 boundary. Hope leaving room for
extra 4 bytes (0x380 - 0x37C) will not matter much?
Functionally it won't matter but it always good to describe the hardware as
accurately as possible and avoid confusion to future developers as to why
extra 4 bytes were used in the device tree.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
On Wed, May 14, 2014 at 11:17 AM, Roger Quadros rog...@ti.com wrote:
On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.
How did you get 0x380?
From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)
arch/arm/boot/dts/omap3.dtsi is using reg = 0x6e00 0x02d0 so
that should be fixed to 0x2d4 too.
Sorry for the noise.
Just figured out that the register space is not numerically arranged in the
TRM.
The last register is P GPMC_BCH_RESULT6_i
0x5000 0308 + (0x 0010 * i)
i = 0 to 7
So size should be 0x37C.
Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
so I aligned the last address to 0x380 boundary. Hope leaving room for
extra 4 bytes (0x380 - 0x37C) will not matter much?
Functionally it won't matter but it always good to describe the hardware as
accurately as possible and avoid confusion to future developers as to why
extra 4 bytes were used in the device tree.
I don't think that aligning makes too much sense since in practice
ioremap() will map a complete page anyways so if we are not using
0x1000 (e.g: PAGE_SIZE on ARM) is just because we want the DT to
strictly model what the hardware registers address size really is.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hello,
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta pe...@ti.com wrote:
From: Minal Shah minalks...@gmail.com
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0 0x100;
+ nand@0,0 {
+ reg = 0 0 0x380;
[...]
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 37a0595..6af775a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -776,6 +776,26 @@
interrupts = 0 343 0x4;
status = disabled;
};
+
+ elm: elm@48078000 {
+ compatible = ti,am3352-elm;
+ reg = 0x48078000 0x2000;
It is really necessary to map all this 8 KB address space for GPMC registers?
I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
that the GPMC module register address space size is 16 MB while in
practice the registers use less than 1 KB (0..0x02d0 to be exact) so
in arch/arm/boot/dts/omap3.dtsi we have:
These are not GPMC registers. Platforms from OMAP4 and beyond
(like AM335x, OMAP5) have another small hardware engine called ELM [1]
(Error Locater Module) in addition to GPMC, which is used for detecting
ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c
However, thanks for pointing out, this address-space for ELM is incorrect.
Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].
gpmc: gpmc@6e00 {
...
reg = 0x6e00 0x02d0;
...
};
Shouldn't this be similar (the same?) for DRA7 GPMC device node?
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
Thanks a lot and best regards,
Javier
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hello Pekon,
On Mon, May 12, 2014 at 9:03 AM, Gupta, Pekon pe...@ti.com wrote:
Hello,
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta pe...@ti.com wrote:
From: Minal Shah minalks...@gmail.com
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0 0x100;
+ nand@0,0 {
+ reg = 0 0 0x380;
[...]
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 37a0595..6af775a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -776,6 +776,26 @@
interrupts = 0 343 0x4;
status = disabled;
};
+
+ elm: elm@48078000 {
+ compatible = ti,am3352-elm;
+ reg = 0x48078000 0x2000;
It is really necessary to map all this 8 KB address space for GPMC registers?
I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
that the GPMC module register address space size is 16 MB while in
practice the registers use less than 1 KB (0..0x02d0 to be exact) so
in arch/arm/boot/dts/omap3.dtsi we have:
These are not GPMC registers. Platforms from OMAP4 and beyond
(like AM335x, OMAP5) have another small hardware engine called ELM [1]
(Error Locater Module) in addition to GPMC, which is used for detecting
ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c
Yes, I know what ELM is, I just made a mistake when adding my comments
inline. I actually meant the 8KB from the following device node:
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ status = disabled;
+ };
However, thanks for pointing out, this address-space for ELM is incorrect.
Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].
And yes, comments applies to ELM register address space as well.
gpmc: gpmc@6e00 {
...
reg = 0x6e00 0x02d0;
...
};
Shouldn't this be similar (the same?) for DRA7 GPMC device node?
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
I see and did the GPMC register space became that big to need to map 8KB?
Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:
reg = 0x6e00 0x02d0;
reg = 0x6e00 0x0400;
reg = 0x6e00 0x1000;
in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org] [...] Newer platforms have upgraded version of GPMC engine which supports BCH16 ECC scheme in hardware. Thus the GPMC address space was expanded to include some extra registers required for BCH16 ECC [2]. I see and did the GPMC register space became that big to need to map 8KB? Although the smallest unit for ioremap is PAGE_SIZE and using any of these reg sizes: reg = 0x6e00 0x02d0; reg = 0x6e00 0x0400; reg = 0x6e00 0x1000; in practice have the same effect, DTS should describe the hardware and not an implementation detail so I think that we should use only the register size that is defined in the TRM. Yes, I agree with you. I have fixed this in newer version of the patch and will be sending it soon. But this series will only contain updates for new platforms with addition of NAND node in DTS, so that this series is not stalled for any reason. For fixing existing platform/boards DTS I'll send another series soon. For now, I'll use GPMC address-space size = 0x380 as it matches with actual hardware and is working. [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5) [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5) (Though the AM335x address space mentions 0x368 as last address, it should be 0x378. I have raised documentation bug for it). with regards, pekon Best regards, Javier [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
On Mon, May 12, 2014 at 11:05 AM, Gupta, Pekon pe...@ti.com wrote: From: Javier Martinez Canillas [mailto:jav...@dowhile0.org] [...] Newer platforms have upgraded version of GPMC engine which supports BCH16 ECC scheme in hardware. Thus the GPMC address space was expanded to include some extra registers required for BCH16 ECC [2]. I see and did the GPMC register space became that big to need to map 8KB? Although the smallest unit for ioremap is PAGE_SIZE and using any of these reg sizes: reg = 0x6e00 0x02d0; reg = 0x6e00 0x0400; reg = 0x6e00 0x1000; in practice have the same effect, DTS should describe the hardware and not an implementation detail so I think that we should use only the register size that is defined in the TRM. Yes, I agree with you. I have fixed this in newer version of the patch and will be sending it soon. But this series will only contain updates for new platforms with addition of NAND node in DTS, so that this series is not stalled for any reason. For fixing existing platform/boards DTS I'll send another series soon. Yes, I agree that fixing existing platforms is a matter of a different series, I just didn't want to introduce more :-) For now, I'll use GPMC address-space size = 0x380 as it matches with actual hardware and is working. Perfect, thanks a lot! [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5) [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5) (Though the AM335x address space mentions 0x368 as last address, it should be 0x378. I have raised documentation bug for it). with regards, pekon Best regards, Javier [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hello Pekon,
On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta pe...@ti.com wrote:
From: Minal Shah minalks...@gmail.com
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah minalks...@gmail.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 117
+
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5f1f6da..ed4e974 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -108,6 +108,37 @@
0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+* So NAND flash requires following switch settings:
+* SW5.9 (GPMC_WPN) = LOW
+* SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT | MUX_MODE0)/* gpmc_ad0
*/
+ 0x4 (PIN_INPUT | MUX_MODE0)/* gpmc_ad1
*/
+ 0x8 (PIN_INPUT | MUX_MODE0)/* gpmc_ad2
*/
+ 0xc (PIN_INPUT | MUX_MODE0)/* gpmc_ad3
*/
+ 0x10(PIN_INPUT | MUX_MODE0)/* gpmc_ad4
*/
+ 0x14(PIN_INPUT | MUX_MODE0)/* gpmc_ad5
*/
+ 0x18(PIN_INPUT | MUX_MODE0)/* gpmc_ad6
*/
+ 0x1c(PIN_INPUT | MUX_MODE0)/* gpmc_ad7
*/
+ 0x20(PIN_INPUT | MUX_MODE0)/* gpmc_ad8
*/
+ 0x24(PIN_INPUT | MUX_MODE0)/* gpmc_ad9
*/
+ 0x28(PIN_INPUT | MUX_MODE0)/* gpmc_ad10
*/
+ 0x2C(PIN_INPUT | MUX_MODE0)/* gpmc_ad11
*/
+ 0x30(PIN_INPUT | MUX_MODE0)/* gpmc_ad12
*/
+ 0x34(PIN_INPUT | MUX_MODE0)/* gpmc_ad13
*/
+ 0x38(PIN_INPUT | MUX_MODE0)/* gpmc_ad14
*/
+ 0x3C(PIN_INPUT | MUX_MODE0)/* gpmc_ad15
*/
+ 0xd8(PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0
*/
+ 0xcc(PIN_OUTPUT | MUX_MODE0)/* gpmc_wen
*/
+ 0xb4(PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0
*/
+ 0xc4(PIN_OUTPUT | MUX_MODE0)/*
gpmc_advn_ale */
+ 0xc8(PIN_OUTPUT | MUX_MODE0)/*
gpmc_oen_ren */
+ 0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
+ ;
+ };
};
i2c1 {
@@ -353,3 +384,89 @@
};
};
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x16;
+ ranges = 0 0 0 0x100;
+ nand@0,0 {
+ reg = 0 0 0x380;
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 16;
+ gpmc,device-width = 2;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 30;
+ gpmc,adv-wr-off-ns = 30;
+ gpmc,we-on-ns = 5;
+ gpmc,we-off-ns = 25;
+ gpmc,oe-on-ns = 2;
+ gpmc,oe-off-ns = 20;
+ gpmc,access-ns = 20;
+ gpmc,wr-access-ns = 40;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 0;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be
