diff mbox

[U-Boot] nand: lpc32xx: add SLC NAND controller support

Message ID 1436905437-19149-1-git-send-email-vz@mleia.com
State Superseded
Headers show

Commit Message

Vladimir Zapolskiy July 14, 2015, 8:23 p.m. UTC
The change adds support of LPC32xx SLC NAND controller.

LPC32xx SoC has two different mutually exclusive NAND controllers to
communicate with single and multiple layer chips.

This simple driver allows to specify NAND chip timings and defines
custom read_buf()/write_buf() operations, because access to 8-bit data
register must be 32-bit aligned.

Support of hardware ECC calculation is not implemented (data
correction is always done by software), since it requires a working
DMA engine.

The driver can be included to an SPL image.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Albert ARIBAUD <albert.u.boot@3adev.fr>
---
 arch/arm/cpu/arm926ejs/lpc32xx/devices.c      |   6 +
 arch/arm/include/asm/arch-lpc32xx/clk.h       |   2 +
 arch/arm/include/asm/arch-lpc32xx/sys_proto.h |   1 +
 drivers/mtd/nand/Makefile                     |   1 +
 drivers/mtd/nand/lpc32xx_nand_slc.c           | 183 ++++++++++++++++++++++++++
 5 files changed, 193 insertions(+)
 create mode 100644 drivers/mtd/nand/lpc32xx_nand_slc.c

Comments

Albert ARIBAUD July 15, 2015, 7:05 a.m. UTC | #1
Hello Vladimir,

On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy <vz@mleia.com>
wrote:
> The change adds support of LPC32xx SLC NAND controller.
> 
> LPC32xx SoC has two different mutually exclusive NAND controllers to
> communicate with single and multiple layer chips.
> 
> This simple driver allows to specify NAND chip timings and defines
> custom read_buf()/write_buf() operations, because access to 8-bit data
> register must be 32-bit aligned.
> 
> Support of hardware ECC calculation is not implemented (data
> correction is always done by software), since it requires a working
> DMA engine.
> 
> The driver can be included to an SPL image.

This is needed for an upcoming new board support patch, right? If so,
then I suggest you put together all patches for this new board in a
single series. This will make it clear(er) you're not adding dead code
here.

> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Albert ARIBAUD <albert.u.boot@3adev.fr>

Amicalement,
Vladimir Zapolskiy July 15, 2015, 8:49 a.m. UTC | #2
Hello Albert,

On 15.07.2015 10:05, Albert ARIBAUD wrote:
> Hello Vladimir,
> 
> On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy <vz@mleia.com>
> wrote:
>> The change adds support of LPC32xx SLC NAND controller.
>> 
>> LPC32xx SoC has two different mutually exclusive NAND controllers 
>> to communicate with single and multiple layer chips.
>> 
>> This simple driver allows to specify NAND chip timings and defines
>>  custom read_buf()/write_buf() operations, because access to 8-bit 
>> data register must be 32-bit aligned.
>> 
>> Support of hardware ECC calculation is not implemented (data 
>> correction is always done by software), since it requires a working
>> DMA engine.
>> 
>> The driver can be included to an SPL image.
> 
> This is needed for an upcoming new board support patch, right?

you are correct, I plan to extend current support of devkit3250 board.

> If so, then I suggest you put together all patches for this new
> board in a single series. This will make it clear(er) you're not
> adding dead code here.
> 

I got the point, I will be able to complete board specific changes today
tonight and send them for review.

Please let me ask you for one more advice, if I want to add peripherals
support on the board (by the way thank you for your drivers) and SPL
image building support, both changes touch defconfig and board config
header files. Should I split these changes into separate ones or is one
"board support extension" patch preferred?

--
With best wishes,
Vladimir
Albert ARIBAUD July 15, 2015, 9:21 a.m. UTC | #3
Hello Vladimir,

On Wed, 15 Jul 2015 11:49:01 +0300, Vladimir Zapolskiy <vz@mleia.com>
wrote:
> Hello Albert,
> 
> On 15.07.2015 10:05, Albert ARIBAUD wrote:
> > Hello Vladimir,
> > 
> > On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy <vz@mleia.com>
> > wrote:
> >> The change adds support of LPC32xx SLC NAND controller.
> >> 
> >> LPC32xx SoC has two different mutually exclusive NAND controllers 
> >> to communicate with single and multiple layer chips.
> >> 
> >> This simple driver allows to specify NAND chip timings and defines
> >>  custom read_buf()/write_buf() operations, because access to 8-bit 
> >> data register must be 32-bit aligned.
> >> 
> >> Support of hardware ECC calculation is not implemented (data 
> >> correction is always done by software), since it requires a working
> >> DMA engine.
> >> 
> >> The driver can be included to an SPL image.
> > 
> > This is needed for an upcoming new board support patch, right?
> 
> you are correct, I plan to extend current support of devkit3250 board.
> 
> > If so, then I suggest you put together all patches for this new
> > board in a single series. This will make it clear(er) you're not
> > adding dead code here.
> > 
> 
> I got the point, I will be able to complete board specific changes today
> tonight and send them for review.

Thanks.

> Please let me ask you for one more advice, if I want to add peripherals
> support on the board (by the way thank you for your drivers) and SPL
> image building support, both changes touch defconfig and board config
> header files. Should I split these changes into separate ones or is one
> "board support extension" patch preferred?

A commit should ideally be a single, self-contained, logical change.

So I would say each driver addition should be one commit, and the SPL
support addition should be its own commit, even though each of these
commits touches the defconfig and header config files.

This has at least two benefits:

- each commit is simpler to review (and to design and test, too). If a
  commit contains several logical changes, it is harder to sort out
  which change(s) a given patch chunk is about.

- in case a change was applied to U-Boot and later proves to cause
  an issue, then we can easily revert this change, and only
  this change, by reverting its commit. If the commit contains
  several change, then we cannot simply revert the commit, we need to
  manually "patch out" the problematic change while keeping the others.

> --
> With best wishes,
> Vladimir

Amicalement,
LEMIEUX, SYLVAIN July 15, 2015, 7:23 p.m. UTC | #4
Hi Vladimir and Albert,

During this merge window (once our issues with our exchange server are resolve), we were planning on submitting a few patches for the LPC32xx.

Some of the patches are the porting of the legacy NXP BSP (u-boot) drivers into the latest version; the drivers are the DMA, the SLC NAND and the USB.

This original NXP implementation of the SLC NAND was using the DMA. I am also planning on testing this patch to compare the flashing time, with and without the DMA.

I have two questions:
1) How do you suggest to approach this, as some patches may be similar or conflicting with what Vladimir is planning on submitting?
2) For submitting legacy NXP BSP driver porting patch, would you like to see a 3 patches series (original driver, checkpatch script fix and the update for latest u-boot) to have history of the change or a single patch with the final result?


Sylvain Lemieux

-----Original Message-----
From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD
Sent: 15-Jul-15 5:21 AM
To: Vladimir Zapolskiy
Cc: Scott Wood; Albert ARIBAUD; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support

Hello Vladimir,

On Wed, 15 Jul 2015 11:49:01 +0300, Vladimir Zapolskiy <vz@mleia.com>
wrote:
> Hello Albert,
>
> On 15.07.2015 10:05, Albert ARIBAUD wrote:
> > Hello Vladimir,
> >
> > On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy
> > <vz@mleia.com>
> > wrote:
> >> The change adds support of LPC32xx SLC NAND controller.
> >>
> >> LPC32xx SoC has two different mutually exclusive NAND controllers
> >> to communicate with single and multiple layer chips.
> >>
> >> This simple driver allows to specify NAND chip timings and defines
> >> custom read_buf()/write_buf() operations, because access to 8-bit
> >> data register must be 32-bit aligned.
> >>
> >> Support of hardware ECC calculation is not implemented (data
> >> correction is always done by software), since it requires a working
> >> DMA engine.
> >>
> >> The driver can be included to an SPL image.
> >
> > This is needed for an upcoming new board support patch, right?
>
> you are correct, I plan to extend current support of devkit3250 board.
>
> > If so, then I suggest you put together all patches for this new
> > board in a single series. This will make it clear(er) you're not
> > adding dead code here.
> >
>
> I got the point, I will be able to complete board specific changes
> today tonight and send them for review.

Thanks.

> Please let me ask you for one more advice, if I want to add
> peripherals support on the board (by the way thank you for your
> drivers) and SPL image building support, both changes touch defconfig
> and board config header files. Should I split these changes into
> separate ones or is one "board support extension" patch preferred?

A commit should ideally be a single, self-contained, logical change.

So I would say each driver addition should be one commit, and the SPL support addition should be its own commit, even though each of these commits touches the defconfig and header config files.

This has at least two benefits:

- each commit is simpler to review (and to design and test, too). If a
  commit contains several logical changes, it is harder to sort out
  which change(s) a given patch chunk is about.

- in case a change was applied to U-Boot and later proves to cause
  an issue, then we can easily revert this change, and only
  this change, by reverting its commit. If the commit contains
  several change, then we cannot simply revert the commit, we need to
  manually "patch out" the problematic change while keeping the others.

> --
> With best wishes,
> Vladimir

Amicalement,
--
Albert.
Albert ARIBAUD July 15, 2015, 8:21 p.m. UTC | #5
Hello SYLVAIN,

On Wed, 15 Jul 2015 19:23:33 +0000, LEMIEUX, SYLVAIN
<slemieux@Tycoint.com> wrote:
> Hi Vladimir and Albert,
> 
> During this merge window (once our issues with our exchange server
> are resolve), we were planning on submitting a few patches for the
> LPC32xx.
> 
> Some of the patches are the porting of the legacy NXP BSP (u-boot)
> drivers into the latest version; the drivers are the DMA, the SLC
> NAND and the USB.
> 
> This original NXP implementation of the SLC NAND was using the DMA. I
> am also planning on testing this patch to compare the flashing time,
> with and without the DMA.
> 
> I have two questions:
> 1) How do you suggest to approach this, as some patches may be
> similar or conflicting with what Vladimir is planning on submitting?

That question is for you and Vladimir to discuss.

> 2) For submitting legacy NXP BSP driver porting patch, would you like
> to see a 3 patches series (original driver, checkpatch script fix and
> the update for latest u-boot) to have history of the change or a
> single patch with the final result?

Single patch with the final result.

Amicalement,
Vladimir Zapolskiy July 16, 2015, 12:19 a.m. UTC | #6
Hi Sylvain,

On 15.07.2015 22:23, LEMIEUX, SYLVAIN wrote:
> Hi Vladimir and Albert,
> 
> During this merge window (once our issues with our exchange server are resolve), we were planning on submitting a few patches for the LPC32xx.

great, feel free to add me to Cc.

> Some of the patches are the porting of the legacy NXP BSP (u-boot) drivers into the latest version; the drivers are the DMA, the SLC NAND and the USB.

If DMA and USB are added, I'll gratefully reuse this on my board :)

> This original NXP implementation of the SLC NAND was using the DMA. I am also planning on testing this patch to compare the flashing time, with and without the DMA.

Sounds good. Also since DMA is going to be supported it would be nice to
add HW ECC calculation to the SLC NAND driver.

FYI here are performance test results of my PIO version:

  => gettime; nand read.raw 0x80000000 0x0 0x6000; gettime
  Timer val: 63952
  Seconds : 63
  Remainder : 952
  sys_hz = 1000

  NAND read:  51904512 bytes read: OK
  Timer val: 113352
  Seconds : 113
  Remainder : 352
  sys_hz = 1000


1.002 MiB per second, quite slow, but not drastically slow.

> I have two questions:
> 1) How do you suggest to approach this, as some patches may be similar or conflicting with what Vladimir is planning on submitting?

I presume the only conflicting place is SLC NAND driver.

Here I see some benefits of my version:

* the driver is very tiny, practically it is read_buf()/write_buf() and
timing configuration, all the rest I managed to offload to existing
mtd/nand and spl/nand frameworks at the price of more added CONFIG_*
defines in a board header file,
* not sure what OOB layout is coming from NXP BSP (I don't have this BSP
to check, unfortunately), but I would prefer to see the same OOB layout
in U-boot and in vanilla Linux --- this is done in my version,
* the driver can be included to SPL binary,
* the driver is well tested on my environment,
* the code has been published for review.

The only two missing things from the driver I see at the moment are
based on working DMA driver:
* data transfer by means of DMA,
* HW ECC calculation (data correction is always done by software).

Also my driver has not been tested with small page NAND chips, not sure,
if it is relevant for you.

If DMA works, I hope it should be easy to add some lpc32xx_chip.ecc.*
callbacks to my version of the driver.

> 2) For submitting legacy NXP BSP driver porting patch, would you like to see a 3 patches series (original driver, checkpatch script fix and the update for latest u-boot) to have history of the change or a single patch with the final result?
> 

If it were related to Linux kernel project, I know the clear answer, but
please let me leave U-boot maintenance specifics to be explained by Albert.

--
With best wishes,
Vladimir

> 
> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD
> Sent: 15-Jul-15 5:21 AM
> To: Vladimir Zapolskiy
> Cc: Scott Wood; Albert ARIBAUD; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support
> 
> Hello Vladimir,
> 
> On Wed, 15 Jul 2015 11:49:01 +0300, Vladimir Zapolskiy <vz@mleia.com>
> wrote:
>> Hello Albert,
>>
>> On 15.07.2015 10:05, Albert ARIBAUD wrote:
>>> Hello Vladimir,
>>>
>>> On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy
>>> <vz@mleia.com>
>>> wrote:
>>>> The change adds support of LPC32xx SLC NAND controller.
>>>>
>>>> LPC32xx SoC has two different mutually exclusive NAND controllers
>>>> to communicate with single and multiple layer chips.
>>>>
>>>> This simple driver allows to specify NAND chip timings and defines
>>>> custom read_buf()/write_buf() operations, because access to 8-bit
>>>> data register must be 32-bit aligned.
>>>>
>>>> Support of hardware ECC calculation is not implemented (data
>>>> correction is always done by software), since it requires a working
>>>> DMA engine.
>>>>
>>>> The driver can be included to an SPL image.
>>>
>>> This is needed for an upcoming new board support patch, right?
>>
>> you are correct, I plan to extend current support of devkit3250 board.
>>
>>> If so, then I suggest you put together all patches for this new
>>> board in a single series. This will make it clear(er) you're not
>>> adding dead code here.
>>>
>>
>> I got the point, I will be able to complete board specific changes
>> today tonight and send them for review.
> 
> Thanks.
> 
>> Please let me ask you for one more advice, if I want to add
>> peripherals support on the board (by the way thank you for your
>> drivers) and SPL image building support, both changes touch defconfig
>> and board config header files. Should I split these changes into
>> separate ones or is one "board support extension" patch preferred?
> 
> A commit should ideally be a single, self-contained, logical change.
> 
> So I would say each driver addition should be one commit, and the SPL support addition should be its own commit, even though each of these commits touches the defconfig and header config files.
> 
> This has at least two benefits:
> 
> - each commit is simpler to review (and to design and test, too). If a
>   commit contains several logical changes, it is harder to sort out
>   which change(s) a given patch chunk is about.
> 
> - in case a change was applied to U-Boot and later proves to cause
>   an issue, then we can easily revert this change, and only
>   this change, by reverting its commit. If the commit contains
>   several change, then we cannot simply revert the commit, we need to
>   manually "patch out" the problematic change while keeping the others.
> 
>> --
>> With best wishes,
>> Vladimir
> 
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> ________________________________
> 
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
>
LEMIEUX, SYLVAIN July 16, 2015, 7:38 p.m. UTC | #7
Hi Vladimir,

Thanks for taking time to read my feedback.
You can see my comments and my answer below.

Sylvain

> -----Original Message-----
> From: Vladimir Zapolskiy [mailto:vz@mleia.com]
> Sent: 15-Jul-15 8:20 PM
> To: LEMIEUX, SYLVAIN; Albert ARIBAUD
> Cc: Scott Wood; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support
>
> Hi Sylvain,
>
> On 15.07.2015 22:23, LEMIEUX, SYLVAIN wrote:
> > Hi Vladimir and Albert,
> >
> > During this merge window (once our issues with our exchange server are
> resolve), we were planning on submitting a few patches for the LPC32xx.
>
> great, feel free to add me to Cc.

Will do;

>
> > Some of the patches are the porting of the legacy NXP BSP (u-boot) drivers
> into the latest version; the drivers are the DMA, the SLC NAND and the USB.
>
> If DMA and USB are added, I'll gratefully reuse this on my board :)

I will submit the LPC32xx patches using an alternate e-mail for now, until the problem with our e-mail infrastructure is resolve.

First, I need to do some rework (matching the naming convention of your NAND SLC patch and update our porting effort based on the feedback from Albert).

>
> > This original NXP implementation of the SLC NAND was using the DMA. I am
> also planning on testing this patch to compare the flashing time, with and
> without the DMA.
>
> Sounds good. Also since DMA is going to be supported it would be nice to
> add HW ECC calculation to the SLC NAND driver.

Hardware ECC was already supported in the legacy BSP; it will be part of the patches I will submit.

>
> FYI here are performance test results of my PIO version:
>
>   => gettime; nand read.raw 0x80000000 0x0 0x6000; gettime
>   Timer val: 63952
>   Seconds : 63
>   Remainder : 952
>   sys_hz = 1000
>
>   NAND read:  51904512 bytes read: OK
>   Timer val: 113352
>   Seconds : 113
>   Remainder : 352
>   sys_hz = 1000
>
>
> 1.002 MiB per second, quite slow, but not drastically slow.

FYI, I did the same testing on my side using the legacy NXP BSP implementation;
the test was done with the CPU clock at 208MHz and 266MHz.

For those test, we have no timing optimization for the SLC NAND.

Clock configuration:
CPU clock: 266MHz / AHB bus clock: 133MHz / Peripheral clock: 13MHz
==> gettime; nand read.raw 0x80000000 0xd00000 0x6000; gettime
Timer val: 22949
Seconds : 22
Remainder : 949
sys_hz = 1000

NAND read:  51904512 bytes read: OK
Timer val: 44803
Seconds : 44
Remainder : 803
sys_hz = 1000
--> 2.265 MiB per second

==> gettime; nand read.e 0x80000000 0xd00000 0x3180000; gettime
Timer val: 66054
Seconds : 66
Remainder : 54
sys_hz = 1000

NAND read: device 0 offset 0xd00000, size 0x3180000
 51904512 bytes read: OK
Timer val: 89214
Seconds : 89
Remainder : 214
sys_hz = 1000
--> 2.137 MiB per second

Clock configuration:
CPU clock: 208MHz / AHB bus clock: 104MHz / Peripheral clock: 13MHz

==> gettime; nand read.raw 0x80000000 0xd00000 0x6000; gettime
Timer val: 24605
Seconds : 24
Remainder : 605
sys_hz = 1000

NAND read:  51904512 bytes read: OK
Timer val: 52458
Seconds : 52
Remainder : 458
sys_hz = 1000
--> 1.777 MiB per second

==> gettime; nand read.e 0x80000000 0x00d00000 0x3180000; gettime
Timer val: 134819
Seconds : 134
Remainder : 819
sys_hz = 1000

NAND read: device 0 offset 0xd00000, size 0x3180000
 51904512 bytes read: OK
Timer val: 164465
Seconds : 164
Remainder : 465
sys_hz = 1000
--> 1.669 MiB per second

>
> > I have two questions:
> > 1) How do you suggest to approach this, as some patches may be similar or
> conflicting with what Vladimir is planning on submitting?
>
> I presume the only conflicting place is SLC NAND driver.

Yes, this will be the only conflicting patch.

>
> Here I see some benefits of my version:
>
> * the driver is very tiny, practically it is read_buf()/write_buf() and timing
> configuration, all the rest I managed to offload to existing mtd/nand and
> spl/nand frameworks at the price of more added CONFIG_* defines in a
> board header file,
> * not sure what OOB layout is coming from NXP BSP (I don't have this BSP to
> check, unfortunately), but I would prefer to see the same OOB layout in U-
> boot and in vanilla Linux --- this is done in my version,
> * the driver can be included to SPL binary,
> * the driver is well tested on my environment,
> * the code has been published for review.

This is the benefits (I am thinking we get) from the legacy NXP BSP porting:
* The driver went through multiple iteration (the latest version of the legacy patch was 1.07).
* The BSP, from LPC Linux, was most likely review and tested by multiple users; it was the initial u-boot reference for the LPC32xx development boards.
* The SLC NAND  implementation is integrated with the DMA, and already support hardware ECC.
* The OOB layout from the legacy BSP is matching the LPC32xx NAND SLC Linux driver.

>
> The only two missing things from the driver I see at the moment are based
> on working DMA driver:
> * data transfer by means of DMA,
> * HW ECC calculation (data correction is always done by software).
>
> Also my driver has not been tested with small page NAND chips, not sure, if it
> is relevant for you.

The legacy BSP driver was only tested with large page NAND on our side.

>
> If DMA works, I hope it should be easy to add some lpc32xx_chip.ecc.*
> callbacks to my version of the driver.
>
> > 2) For submitting legacy NXP BSP driver porting patch, would you like to see
> a 3 patches series (original driver, checkpatch script fix and the update for
> latest u-boot) to have history of the change or a single patch with the final
> result?
> >
>
> If it were related to Linux kernel project, I know the clear answer, but please
> let me leave U-boot maintenance specifics to be explained by Albert.
>
> --
> With best wishes,
> Vladimir
>
diff mbox

Patch

diff --git a/arch/arm/cpu/arm926ejs/lpc32xx/devices.c b/arch/arm/cpu/arm926ejs/lpc32xx/devices.c
index 5a453e3..b0287be 100644
--- a/arch/arm/cpu/arm926ejs/lpc32xx/devices.c
+++ b/arch/arm/cpu/arm926ejs/lpc32xx/devices.c
@@ -54,6 +54,12 @@  void lpc32xx_mlc_nand_init(void)
 	writel(CLK_NAND_MLC | CLK_NAND_MLC_INT, &clk->flashclk_ctrl);
 }
 
+void lpc32xx_slc_nand_init(void)
+{
+	/* Enable SLC NAND interface */
+	writel(CLK_NAND_SLC | CLK_NAND_SLC_SELECT, &clk->flashclk_ctrl);
+}
+
 void lpc32xx_i2c_init(unsigned int devnum)
 {
 	/* Enable I2C interface */
diff --git a/arch/arm/include/asm/arch-lpc32xx/clk.h b/arch/arm/include/asm/arch-lpc32xx/clk.h
index 9449869..010211a 100644
--- a/arch/arm/include/asm/arch-lpc32xx/clk.h
+++ b/arch/arm/include/asm/arch-lpc32xx/clk.h
@@ -153,7 +153,9 @@  struct clk_pm_regs {
 #define CLK_DMA_ENABLE			(1 << 0)
 
 /* NAND Clock Control Register bits */
+#define CLK_NAND_SLC			(1 << 0)
 #define CLK_NAND_MLC			(1 << 1)
+#define CLK_NAND_SLC_SELECT		(1 << 2)
 #define CLK_NAND_MLC_INT		(1 << 5)
 
 /* SSP Clock Control Register bits */
diff --git a/arch/arm/include/asm/arch-lpc32xx/sys_proto.h b/arch/arm/include/asm/arch-lpc32xx/sys_proto.h
index c3d890d..0845f83 100644
--- a/arch/arm/include/asm/arch-lpc32xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-lpc32xx/sys_proto.h
@@ -12,6 +12,7 @@ 
 void lpc32xx_uart_init(unsigned int uart_id);
 void lpc32xx_mac_init(void);
 void lpc32xx_mlc_nand_init(void);
+void lpc32xx_slc_nand_init(void);
 void lpc32xx_i2c_init(unsigned int devnum);
 void lpc32xx_ssp_init(void);
 #if defined(CONFIG_SPL_BUILD)
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index f3da70b..0813b54 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -54,6 +54,7 @@  obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
 obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
 obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
 obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o
+obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o
 obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
 obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
 obj-$(CONFIG_NAND_MXC) += mxc_nand.o
diff --git a/drivers/mtd/nand/lpc32xx_nand_slc.c b/drivers/mtd/nand/lpc32xx_nand_slc.c
new file mode 100644
index 0000000..c888dd6
--- /dev/null
+++ b/drivers/mtd/nand/lpc32xx_nand_slc.c
@@ -0,0 +1,183 @@ 
+/*
+ * LPC32xx SLC NAND flash controller driver
+ *
+ * (C) Copyright 2015 Vladimir Zapolskiy <vz@mleia.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <nand.h>
+#include <asm/errno.h>
+#include <asm/io.h>
+#include <asm/arch/clk.h>
+#include <asm/arch/sys_proto.h>
+
+struct lpc32xx_nand_slc_registers {
+	u32 data;
+	u32 addr;
+	u32 cmd;
+	u32 stop;
+	u32 ctrl;
+	u32 cfg;
+	u32 stat;
+	u32 int_stat;
+	u32 ien;
+	u32 isr;
+	u32 icr;
+	u32 tac;
+	u32 tc;
+	u32 ecc;
+	u32 dma_data;
+};
+
+/* CFG register */
+#define CFG_CE_LOW		(1 << 5)
+#define CFG_ECC_EN		(1 << 3)
+
+/* CTRL register */
+#define CTRL_SW_RESET		(1 << 2)
+#define CTRL_ECC_CLEAR		(1 << 1)
+
+/* STAT register */
+#define STAT_NAND_READY		(1 << 0)
+
+/* INT_STAT register */
+#define INT_STAT_TC		(1 << 1)
+#define INT_STAT_RDY		(1 << 0)
+
+/* TAC register bits, be aware of overflows */
+#define TAC_W_RDY(n)		(max_t(uint32_t, (n), 0xF) << 28)
+#define TAC_W_WIDTH(n)		(max_t(uint32_t, (n), 0xF) << 24)
+#define TAC_W_HOLD(n)		(max_t(uint32_t, (n), 0xF) << 20)
+#define TAC_W_SETUP(n)		(max_t(uint32_t, (n), 0xF) << 16)
+#define TAC_R_RDY(n)		(max_t(uint32_t, (n), 0xF) << 12)
+#define TAC_R_WIDTH(n)		(max_t(uint32_t, (n), 0xF) << 8)
+#define TAC_R_HOLD(n)		(max_t(uint32_t, (n), 0xF) << 4)
+#define TAC_R_SETUP(n)		(max_t(uint32_t, (n), 0xF) << 0)
+
+static struct lpc32xx_nand_slc_registers __iomem *lpc32xx_nand_slc_registers
+	= (struct lpc32xx_nand_slc_registers __iomem *)SLC_NAND_BASE;
+
+static void lpc32xx_nand_init(void)
+{
+	uint32_t hclk = get_hclk_clk_rate();
+
+	/* Reset SLC NAND controller */
+	writel(CTRL_SW_RESET, &lpc32xx_nand_slc_registers->ctrl);
+
+	/* 8-bit bus, no DMA, no ECC, ordinary CE signal */
+	writel(0, &lpc32xx_nand_slc_registers->cfg);
+
+	/* Interrupts disabled and cleared */
+	writel(0, &lpc32xx_nand_slc_registers->ien);
+	writel(INT_STAT_TC | INT_STAT_RDY,
+	       &lpc32xx_nand_slc_registers->icr);
+
+	/* Configure NAND flash timings */
+	writel(TAC_W_RDY(CONFIG_LPC32XX_NAND_SLC_WDR_CLKS) |
+	       TAC_W_WIDTH(hclk / CONFIG_LPC32XX_NAND_SLC_WWIDTH) |
+	       TAC_W_HOLD(hclk / CONFIG_LPC32XX_NAND_SLC_WHOLD) |
+	       TAC_W_SETUP(hclk / CONFIG_LPC32XX_NAND_SLC_WSETUP) |
+	       TAC_R_RDY(CONFIG_LPC32XX_NAND_SLC_RDR_CLKS) |
+	       TAC_R_WIDTH(hclk / CONFIG_LPC32XX_NAND_SLC_RWIDTH) |
+	       TAC_R_HOLD(hclk / CONFIG_LPC32XX_NAND_SLC_RHOLD) |
+	       TAC_R_SETUP(hclk / CONFIG_LPC32XX_NAND_SLC_RSETUP),
+	       &lpc32xx_nand_slc_registers->tac);
+}
+
+static void lpc32xx_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+	debug("ctrl: 0x%08x, cmd: 0x%08x\n", ctrl, cmd);
+
+	if (ctrl & NAND_NCE)
+		setbits_le32(&lpc32xx_nand_slc_registers->cfg, CFG_CE_LOW);
+	else
+		clrbits_le32(&lpc32xx_nand_slc_registers->cfg, CFG_CE_LOW);
+
+	if (cmd == NAND_CMD_NONE)
+		return;
+
+	if (ctrl & NAND_CLE)
+		writel(cmd & 0xFF, &lpc32xx_nand_slc_registers->cmd);
+	else /* if (ctrl & NAND_ALE) */
+		writel(cmd & 0xFF, &lpc32xx_nand_slc_registers->addr);
+}
+
+static int lpc32xx_nand_dev_ready(struct mtd_info *mtd)
+{
+	return readl(&lpc32xx_nand_slc_registers->stat) & STAT_NAND_READY;
+}
+
+static void lpc32xx_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+	while (len-- > 0)
+		*buf++ = (uint8_t)readl(&lpc32xx_nand_slc_registers->data);
+}
+
+static uint8_t lpc32xx_read_byte(struct mtd_info *mtd)
+{
+	return (uint8_t)readl(&lpc32xx_nand_slc_registers->data);
+}
+
+static void lpc32xx_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+	while (len-- > 0)
+		writel((uint32_t)*buf++, &lpc32xx_nand_slc_registers->data);
+}
+
+static void lpc32xx_write_byte(struct mtd_info *mtd, uint8_t byte)
+{
+	writel((uint32_t)byte, &lpc32xx_nand_slc_registers->data);
+}
+
+/*
+ * LPC32xx has only one SLC NAND controller, don't utilize
+ * CONFIG_SYS_NAND_SELF_INIT to be able to reuse this function
+ * both in SPL NAND and U-boot images.
+ */
+int board_nand_init(struct nand_chip *lpc32xx_chip)
+{
+	lpc32xx_chip->IO_ADDR_R	= &lpc32xx_nand_slc_registers->data;
+	lpc32xx_chip->IO_ADDR_W	= &lpc32xx_nand_slc_registers->data;
+
+	lpc32xx_chip->cmd_ctrl	= lpc32xx_nand_cmd_ctrl;
+	lpc32xx_chip->dev_ready	= lpc32xx_nand_dev_ready;
+
+	/*
+	 * Hardware ECC calculation is not supported by the driver, because it
+	 * requires DMA support, see Note after SLC_ECC register description
+	 */
+	lpc32xx_chip->ecc.mode	= NAND_ECC_SOFT;
+
+	/*
+	 * The implementation of these functions is quite common, but
+	 * they MUST be defined, because access to data register
+	 * is strictly 32-bit aligned.
+	 */
+	lpc32xx_chip->read_buf	= lpc32xx_read_buf;
+	lpc32xx_chip->read_byte	= lpc32xx_read_byte;
+	lpc32xx_chip->write_buf	= lpc32xx_write_buf;
+	lpc32xx_chip->write_byte	= lpc32xx_write_byte;
+
+	/*
+	 * Use default ECC layout, but these values are predefined
+	 * for both small and large page NAND flash devices.
+	 */
+	lpc32xx_chip->ecc.size	= 256;
+	lpc32xx_chip->ecc.bytes	= 3;
+	lpc32xx_chip->ecc.strength	= 1;
+
+#if defined(CONFIG_SPL_BUILD)
+	lpc32xx_chip->options		|= NAND_SKIP_BBTSCAN;
+#endif
+
+#if defined(CONFIG_SYS_NAND_USE_FLASH_BBT)
+	lpc32xx_chip->bbt_options	|= NAND_BBT_USE_FLASH;
+#endif
+
+	/* Initialize NAND interface */
+	lpc32xx_nand_init();
+
+	return 0;
+}