mxc nand: Add support for i.MX5

This patches fixes the TODO to use same register definitions in mtd mxc_nand and nand_spl fsl nfc drivers.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

Quoted 8 lines

This patches fixes the TODO to use same register definitions in mtd mxc_nand and
nand_spl fsl nfc drivers.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

Hi Beno?t,

before going deeper in the review there is a general issue.

nand_spl was used in the past and it was the first implementation to have a first loader able to copy u-boot into RAM when the SOC boots from
NAND. It is replaced by the general SPL framework. All new implementations must use the new SPL framework, What you see under nand_spl is referred to already supported boards.

With general SPL, we do not have two drivers for NAND, and we are able
to boot from other devices, too. So it makes no sense to try to uniform
the driver under nand_spl with the main driver, we want to use only the
main driver.

Then, I don't know what to do with these patches.

Note that this is not a new implementation, but only an enhancement of the existing one. But I understand your point.

I don't see any i.MX board using the general SPL for NAND.

So we can't say that
it's usable with the current mtd mxc_nand driver in its current state. Moreover, with the general SPL, I'd be very concerned as to the code size of mxc_nand (the target size of the whole SPL code is only 2 kiB for current i.MX users of nand_spl).

IMHO, we could improve and fix the nand_spl code while it's still there and used.

This does not prevent from moving to the general SPL once ready for mxc_nand. These are two different topics.

Quoted 1 line

Then, I don't know what to do with these patches.

I see two main points in your patches. You cleanup mxc-nand code and add
support for i.MX5. This is one topic, and it can go on.

Quoted 3 lines

Note that this is not a new implementation, but only an enhancement of the
existing one. But I understand your point.

;-)

Quoted 2 lines

I don't see any i.MX board using the general SPL for NAND.

At least the MX28, and using nand_spl with MX28 was rejected for the same reason when it was pushed. Then it was switched to SPL.

But surely it should be better to have more examples - I am working to
get a MX35 booting from external SD, and using the SPL.

Quoted 8 lines

So we can't say that
it's usable with the current mtd mxc_nand driver in its current state. Moreover,
with the general SPL, I'd be very concerned as to the code size of mxc_nand (the
target size of the whole SPL code is only 2 kiB for current i.MX users of
nand_spl).

Mainly because the restriction came from the original implementation, that was for PowerPC 4xx with only a small buffer (NFC buffer) to copy
data from NAND.

We have currently only two boards supporting this mechanismus, using MX25 (karo tx25) and MX31. Both MX25 and MX31 have an internal RAM (128KB) that is is suitable for installing the SPL. Note that TI SOCs have less RAM available, and they support SPL.

IMHO the fact that only two IMX boards are using this mechanism (nand_spl) is also due the fact that is not very flexible. And moving to
SPL we are not fixed to boot exclusively from NAND,

Quoted 3 lines

IMHO, we could improve and fix the nand_spl code while it's still there and
used.

However, as you say, if the code is still available, this makes people
think that is the correct way to do and we will have two distinct implementation (the old one and the new one), both to be supported.

Not to forget that the SPL is thought to work with different SOCs, even
if currently it is mainly used by TI, and with different media storage.
All features taht we discussed previously in the ML if we had to add them to nand_spl, before the new implementation was pushed.

Quoted 2 lines

This does not prevent from moving to the general SPL once ready for mxc_nand. These are two different topics.

The fact is it will be nice if also the two supported boards will move
to SPL.

Of couse, we cannot break these boards,

but a move will be
more
difficult if we increase the number of boards using nand_spl.

Hi Stefano,

Quoted 4 lines

We have currently only two boards supporting this mechanismus, using MX25 (karo tx25) and MX31. Both MX25 and MX31 have an internal RAM (128KB) that is is suitable for installing the SPL. Note that TI SOCs have less RAM available, and they support SPL.

The available RAM size is not the issue. i.MX boards using nand_spl can use internal or external RAM. The issue comes from the i.MX ROM bootloader that only uses the NFC buffer. On i.MX31, that means max 2 kiB for SPL, and 4 kiB on i.MX25/35/51. What can be done on the latter if using internal boot (with DCD header) is to use at most one NF block (more is not possible because the i.MX bootloader goes back to serial mode if any bad block is found, and one of the 1st or 2nd block has to be good).

Quoted 2 lines

Of couse, we cannot break these boards,

They're already broken with the current nand_spl. See my 07/13.

Quoted 3 lines

but a move will be
more
difficult if we increase the number of boards using nand_spl.

Sure, but my series does not add new boards.

Just tell me what to do. I don't have time to port nand_spl boards to general SPL. The only thing I may find time for is to refactor the series in an acceptable way for you.

Quoted 2 lines

Hi Stefano,

Hi Beno?t,

Quoted 7 lines

Quoted 6 lines

We have currently only two boards supporting this mechanismus, using
MX25 (karo tx25) and MX31. Both MX25 and MX31 have an internal RAM (128KB) that is is suitable for installing the SPL. Note that TI SOCs
have less RAM available, and they support SPL.

Quoted 13 lines

The available RAM size is not the issue. i.MX boards using nand_spl can use
internal or external RAM. The issue comes from the i.MX ROM bootloader that only
uses the NFC buffer. On i.MX31, that means max 2 kiB for SPL, and 4 kiB on
i.MX25/35/51. What can be done on the latter if using internal boot (with DCD
header) is to use at most one NF block (more is not possible because the i.MX
bootloader goes back to serial mode if any bad block is found, and one of the
1st or 2nd block has to be good).

We are both a little off-topic here, but because we are reading probably
the same part of the manuals I would like to clear this point.

What you are saying is not exactly what I read from the manual - I checked it now in mx35, I will take a look also on the other ones.

In 7.4.1.6 NAND Flash Boot Operation, I read:

"1. On device power-on, the boot ROM copies the first 4 Kbytes of boot
code from the NAND Flash to the NFC buffer."

So this correspond to your statement - and DCD tables go into NFC buffer. DCD table must be smaller as 4KB, but this is always the case.

"2. ROM code checks the first 4 Kbytes of boot data copied in step 1 above.
a) If no ECC error, then DCD is verified.
? If DCD verification is successful, then the rest of the boot code image is copied to destination RAM (internal RAM or SDRAM) and secure boot is performed."

I understand this part as the mx35 goes on to copy the whole image, depending on the size set into the header, to the address specified in
the table itself. There is no limitation. Exactly in the same way it works on i.MX5 (I know, this does not mean nothing, but..)

I think the limitation of 2KB or 4KB is not correct and is valid only for the DCD data. Do you agree ?

Quoted 4 lines

Quoted 1 line

Of couse, we cannot break these boards,

They're already broken with the current nand_spl. See my 07/13.

Mmmhh...a bug is a bug, and should be fixed, I agree with you on this point.

Quoted 5 lines

Quoted 3 lines

but a move will be
more
difficult if we increase the number of boards using nand_spl.

Sure, but my series does not add new boards.

Right. Maybe I was expecting a new patch series from you adding a new board, because I thought you have a "use case" for i.MX5, (that means,
support for NAND in i.MX5). In other words, a new board based on nand_spl will be not accepted.

But again, fixing current issues is another thing. I will go on on to review the rest of patches (I admit I skip the rest of nand_spl related
patches).

Quoted 5 lines

Just tell me what to do. I don't have time to port nand_spl boards to general
SPL. The only thing I may find time for is to refactor the series in an
acceptable way for you.

You convinced me that you are fixing current issues in already supported
boards - then it is fine with me to go on with this patchset.

Hi Stefano,

Quoted 32 lines · Beno?t Th?baudeau

Quoted 2 lines

Hi Stefano,

Hi Beno?t,

Quoted 17 lines

Quoted 7 lines

We have currently only two boards supporting this mechanismus, using
MX25 (karo tx25) and MX31. Both MX25 and MX31 have an internal RAM
(128KB) that is is suitable for installing the SPL. Note that TI SOCs
have less RAM available, and they support SPL.

The available RAM size is not the issue. i.MX boards using nand_spl
can use
internal or external RAM. The issue comes from the i.MX ROM bootloader that only
uses the NFC buffer. On i.MX31, that means max 2 kiB for SPL, and 4
kiB on
i.MX25/35/51. What can be done on the latter if using internal

Quoted 8 lines

boot
(with DCD
header) is to use at most one NF block (more is not possible because the i.MX
bootloader goes back to serial mode if any bad block is found, and
one of the
1st or 2nd block has to be good).

Quoted 3 lines

We are both a little off-topic here, but because we are reading probably
the same part of the manuals I would like to clear this point.

OK.

Quoted 5 lines

What you are saying is not exactly what I read from the manual - I checked it now in mx35, I will take a look also on the other ones.

In 7.4.1.6 NAND Flash Boot Operation, I read:

Quoted 7 lines

"1. On device power-on, the boot ROM copies the first 4 Kbytes of boot
code from the NAND Flash to the NFC buffer."

So this correspond to your statement - and DCD tables go into NFC buffer. DCD table must be smaller as 4KB, but this is always the case.

Indeed.

Quoted 16 lines

"2. ROM code checks the first 4 Kbytes of boot data copied in step 1
above.
a) If no ECC error, then DCD is verified.
? If DCD verification is successful, then the rest of the boot code image is copied to destination RAM (internal RAM or SDRAM) and secure
boot is performed."

I understand this part as the mx35 goes on to copy the whole image, depending on the size set into the header, to the address specified in
the table itself. There is no limitation. Exactly in the same way it
works on i.MX5 (I know, this does not mean nothing, but..)

Quoted 3 lines

I think the limitation of 2KB or 4KB is not correct and is valid only
for the DCD data. Do you agree ?

No, it's way more complicated than that.

First, there various boot modes available depending on the device for NAND:
i.MX31: external only

i.MX25 and i.MX35: internal or external
i.MX51: internal only

External means that the NFC buffer is filled from NAND and executed without any
DCD or flash header. The limit is 2 kiB on i.MX31. On i.MX25 and i.MX35, it is
not clear from the RMs if only a single NF page is read, or if the NFC buffer is
fully filled (4 kiB). This is the use case for mx31pdk and tx25.

Internal means that 4 kiB are read from NF. If this fails from the 1st block, it
is retried with the 2nd block. If it fails again, boot is aborted. If it
succeeds, DCD and Flash headers are checked and executed. The behavior of the
ROM bootloader while loading the image indicated by the headers is

not clear
from the RMs in case of bad blocks, so I asked FSL support which told me that
as soon as a bad block is found, the boot is aborted. This means that an SPL is
required for NAND boot to be reliable, even with internal boot. This also means
that this SPL can not be larger than a single block.

Hi Stefano,

Quoted 11 lines

Quoted 10 lines

I understand this part as the mx35 goes on to copy the whole image, depending on the size set into the header, to the address specified in
the table itself. There is no limitation. Exactly in the same way it
works on i.MX5 (I know, this does not mean nothing, but..)

I think the limitation of 2KB or 4KB is not correct and is valid only
for the DCD data. Do you agree ?

Quoted 5 lines

No, it's way more complicated than that.

First, there various boot modes available depending on the device for NAND:
i.MX31: external only

Note that internal NAND Flash boot is also mentioned in the RM, but without further details.

FSL should be contacted to know more. But the RM refers to
secure boot and HAB, so it's probably something close to the internal boot modes of i.MX25 and i.MX35.
Anyway, it does not seem to be used by U-Boot i.MX31
boards.

The details about external NF boot are in the NFC chapter of the RMs. For i.MX31, it's perfectly clear: The whole 2-kiB NFC buffer is filled whether the NF pages are 512-B or 2-kiB. For i.MX25 and i.MX35, it's more difficult to find the details, but I interpret the RMs as meaning that the whole 4-kiB NFC buffer is filled whatever the NF page sizes. In both cases, the code is run from the NFC buffer, so that the SPL size cannot exceed 2 kiB for mx31pdk, and 4 kiB for tx25.

Quoted 6 lines

Internal means that 4 kiB are read from NF. If this fails from the 1st block, it
is retried with the 2nd block. If it fails again, boot is aborted. If it
succeeds, DCD and Flash headers are checked and executed.

The

Quoted 10 lines

behavior of the
ROM bootloader while loading the image indicated by the headers is not clear
from the RMs in case of bad blocks, so I asked FSL support which told me that
as soon as a bad block is found, the boot is aborted. This means that an SPL is
required for NAND boot to be reliable, even with internal boot. This also means
that this SPL can not be larger than a single block.

Quoted 7 lines · Beno?t Th?baudeau

This patches fixes the TODO to use same register definitions in mtd mxc_nand and nand_spl fsl nfc drivers.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

Hi Beno?t,

before going deeper in the review there is a general issue.

nand_spl was used in the past and it was the first implementation to have a first loader able to copy u-boot into RAM when the SOC boots from NAND. It is replaced by the general SPL framework. All new implementations must use the new SPL framework, What you see under nand_spl is referred to already supported boards.

With general SPL, we do not have two drivers for NAND, and we are able to boot from other devices, too. So it makes no sense to try to uniform the driver under nand_spl with the main driver, we want to use only the main driver.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
 .../drivers/mtd/nand/mxc_nand.c                    |    9 +++------
 .../include/fsl_nfc.h                              |    1 +
 .../nand_spl/nand_boot_fsl_nfc.c                   |   14 +++++++-------
 3 files changed, 11 insertions(+), 13 deletions(-)

drivers/mtd/nand/mxc_nand.c +3 -6

index 9a9260c..62d8c6b 100644
@@ -123,8 +123,7 @@ static int is_16bit_nand(void)
 #elif defined(CONFIG_MX25) || defined(CONFIG_MX35)
 static int is_16bit_nand(void)
 {
-	struct ccm_regs *ccm =
-		(struct ccm_regs *)IMX_CCM_BASE;
+	struct ccm_regs *ccm = (struct ccm_regs *)IMX_CCM_BASE;
 
 	if (readl(&ccm->rcsr) & CCM_RCSR_NF_16BIT_SEL)
 		return 1;

@@ -238,7 +237,7 @@ static void send_prog_page(struct mxc_nand_host *host, uint8_t buf_id,
 		if (spare_only)
 			config1 |= NFC_SP_EN;
 		else
-			config1 &= ~(NFC_SP_EN);
+			config1 &= ~NFC_SP_EN;
 		writew(config1, &host->regs->config1);
 	}
 

@@ -687,7 +686,6 @@ static int mxc_nand_correct_data(struct mtd_info *mtd, u_char *dat,
 #define mxc_nand_write_page_syndrome NULL
 #define mxc_nand_write_page_raw_syndrome NULL
 #define mxc_nand_write_oob_syndrome NULL
-#define mxc_nfc_11_nand_correct_data NULL
 
 static int mxc_nand_correct_data(struct mtd_info *mtd, u_char *dat,
 				 u_char *read_ecc, u_char *calc_ecc)

@@ -1188,7 +1186,6 @@ int board_nand_init(struct nand_chip *this)
 {
 	struct mtd_info *mtd;
 	uint16_t tmp;
-	int err = 0;
 
 #ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
 	this->options |= NAND_USE_FLASH_BBT;

@@ -1287,5 +1284,5 @@ int board_nand_init(struct nand_chip *this)
 	this->ecc.layout = &nand_hw_eccoob;
 #endif
 	mxc_setup_config1();
-	return err;
+	return 0;
 }

include/fsl_nfc.h +1 -0

index 6691e41..1c16c71 100644
@@ -166,5 +166,6 @@ struct fsl_nfc_regs {
 #define NFC_RST		(1 << 6)
 #define NFC_CE		(1 << 7)
 #define NFC_ONE_CYCLE	(1 << 8)
+#define NFC_FP_INT	(1 << 11)
 
 #endif /* __FSL_NFC_H */

nand_spl/nand_boot_fsl_nfc.c +6 -6

index f437deb..b90f93e 100644
@@ -45,10 +45,10 @@ static void nfc_wait_ready(void)
 	writew(tmp, &nfc->config2);
 }
 
-void nfc_nand_init(void)
+static void nfc_nand_init(void)
 {
 #if defined(MXC_NFC_V1_1)
-	int ecc_per_page  = CONFIG_SYS_NAND_PAGE_SIZE / 512;
+	int ecc_per_page = CONFIG_SYS_NAND_PAGE_SIZE / 512;
 	int config1;
 
 	writew(CONFIG_SYS_NAND_SPARE_SIZE / 2, &nfc->spare_area_size);

@@ -57,12 +57,12 @@ void nfc_nand_init(void)
 	writew(0x2, &nfc->config);
 
 	/* hardware ECC checking and correct */
-	config1 = readw(&nfc->config1) | NFC_ECC_EN | 0x800;
+	config1 = readw(&nfc->config1) | NFC_ECC_EN | NFC_FP_INT;
 	/*
 	 * if spare size is larger that 16 bytes per 512 byte hunk
 	 * then use 8 symbol correction instead of 4
 	 */
-	if ((CONFIG_SYS_NAND_SPARE_SIZE / ecc_per_page) > 16)
+	if (CONFIG_SYS_NAND_SPARE_SIZE / ecc_per_page > 16)
 		config1 &= ~NFC_4_8N_ECC;
 	else
 		config1 |= NFC_4_8N_ECC;

@@ -133,7 +133,7 @@ static void nfc_nand_data_output(void)
 	 * This NAND controller requires multiple input commands
 	 * for pages larger than 512 bytes.
 	 */
-	for (i = 1; i < (CONFIG_SYS_NAND_PAGE_SIZE / 512); i++) {
+	for (i = 1; i < CONFIG_SYS_NAND_PAGE_SIZE / 512; i++) {
 		config1 = readw(&nfc->config1);
 		config1 |= NFC_ECC_EN | NFC_INT_MSK;
 		writew(config1, &nfc->config1);

@@ -171,7 +171,7 @@ static int nfc_read_page(unsigned int page_address, unsigned char *buf)
 	dst = (u32 *)buf;
 
 	/* main copy loop from NAND-buffer to SDRAM memory */
-	for (i = 0; i < (CONFIG_SYS_NAND_PAGE_SIZE / 4); i++) {
+	for (i = 0; i < CONFIG_SYS_NAND_PAGE_SIZE / 4; i++) {
 		writel(readl(src), dst);
 		src++;
 		dst++;

Merge duplicated code into functions, which is better for SPL size too.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

On the NFC IP 1.1, the 32-bit ecc_status_result value comes from 2 consecutive 16-bit registers. This patch reads all the fields of this value, which makes a difference for 4-kiB NF pages.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
 .../drivers/mtd/nand/mxc_nand.c                    |    2 +-
 .../include/fsl_nfc.h                              |    3 +--
 .../nand_spl/nand_boot_fsl_nfc.c                   |    4 ++++
 3 files changed, 6 insertions(+), 3 deletions(-)

drivers/mtd/nand/mxc_nand.c +1 -1

index 62d8c6b..4564b25 100644
@@ -653,7 +653,7 @@ static int mxc_nand_correct_data(struct mtd_info *mtd, u_char *dat,
 {
 	struct nand_chip *nand_chip = mtd->priv;
 	struct mxc_nand_host *host = nand_chip->priv;
-	uint16_t ecc_status = readw(&host->regs->ecc_status_result);
+	uint32_t ecc_status = readl(&host->regs->ecc_status_result);
 	int subpages = mtd->writesize / nand_chip->subpagesize;
 	int pg2blk_shift = nand_chip->phys_erase_shift -
 			   nand_chip->page_shift;

include/fsl_nfc.h +1 -2

index 1c16c71..c248cef 100644
@@ -94,8 +94,7 @@ struct fsl_nfc_regs {
 	u16 flash_addr;
 	u16 flash_cmd;
 	u16 config;
-	u16 ecc_status_result;
-	u16 ecc_status_result2;
+	u32 ecc_status_result;
 	u16 spare_area_size;
 	u16 wrprot;
 	u16 reserved3[2];

nand_spl/nand_boot_fsl_nfc.c +0 -0

index 842943c..4c5a7fe 100644

Quoted 2 lines · Beno?t Th?baudeau

On the NFC IP 1.1, the 32-bit ecc_status_result value comes from 2 consecutive 16-bit registers. This patch reads all the fields of

this value,

Quoted 5 lines

which makes a difference for 4-kiB NF pages.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

Review

Quoted 7 lines

---
 .../drivers/mtd/nand/mxc_nand.c                    |    2 +-
 .../include/fsl_nfc.h                              |    3 +--
 .../nand_spl/nand_boot_fsl_nfc.c                   |    4 ++++
 3 files changed, 6 insertions(+), 3 deletions(-)

(quoted diff) +0 -0

u-boot-4d3c95f/drivers/mtd/nand/mxc_nand.c

drivers/mtd/nand/mxc_nand.c static int mxc_nand_correct_data(struct

Quoted 4 lines

index 62d8c6b..4564b25 100644

drivers/mtd/nand/mxc_nand.c +0 -0

@@ -653,7 +653,7 @@ static int mxc_nand_correct_data(struct  

mtd_info *mtd, u_char *dat,

Review

Quoted 9 lines

drivers/mtd/nand/mxc_nand.c +1 -1

 {
 	struct nand_chip *nand_chip = mtd->priv;
 	struct mxc_nand_host *host = nand_chip->priv;
-	uint16_t ecc_status = readw(&host->regs->ecc_status_result);
+	uint32_t ecc_status = readl(&host->regs->ecc_status_result);
 	int subpages = mtd->writesize / nand_chip->subpagesize;
 	int pg2blk_shift = nand_chip->phys_erase_shift -
 			   nand_chip->page_shift;

(quoted diff) +0 -0

u-boot-4d3c95f/include/fsl_nfc.h

Review

Quoted 14 lines

index 1c16c71..c248cef 100644

include/fsl_nfc.h +1 -2

@@ -94,8 +94,7 @@ struct fsl_nfc_regs {
 	u16 flash_addr;
 	u16 flash_cmd;
 	u16 config;
-	u16 ecc_status_result;
-	u16 ecc_status_result2;
+	u32 ecc_status_result;
 	u16 spare_area_size;
 	u16 wrprot;
 	u16 reserved3[2];

(quoted diff) +0 -0

u-boot-4d3c95f/nand_spl/nand_boot_fsl_nfc.c

Quoted 5 lines

index 842943c..4c5a7fe 100644

nand_spl/nand_boot_fsl_nfc.c +0 -0

@@ -139,7 +139,11 @@ static void nfc_nand_data_output(void)
 

nand_spl/nand_boot_fsl_nfc.c static void nfc_nand_data_output(void) · line 147

Quoted 8 lines

nand_spl/nand_boot_fsl_nfc.c +4 -0

 static int nfc_nand_check_ecc(void)
 {
+#if defined(MXC_NFC_V1)
 	return readw(&nfc->ecc_status_result);
+#elif defined(MXC_NFC_V1_1)
+	return readl(&nfc->ecc_status_result);
+#endif
 }

On MXC_NFC_V1 you're using readw() on a u32 -- that's not OK, even if the
ARM accessors let you get away with it. Use a union or #ifdef the struct
definition, or just always readl() if you can get away with it, or do two
readw()s on V1_1.

Use _mxc_nand_enable_hwecc() instead of duplicating its code.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

Quoted 6 lines

Use _mxc_nand_enable_hwecc() instead of duplicating its code.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

Hi Beno?t,

Quoted 1 line

drivers/mtd/nand/mxc_nand.c static void _mxc_nand_enable_hwecc(struct mtd_info *mtd, int on) · line 378

Quoted 8 lines

drivers/mtd/nand/mxc_nand.c +8 -0

+#ifdef CONFIG_MXC_NAND_HWECC
+static void mxc_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+	/*
+	 * If HW ECC is enabled, we turn it on during init. There is
+	 * no need to enable again here.
+	 */
+}

mxc_nand_enable_hwecc is still empty after your changes...

Quoted 8 lines

drivers/mtd/nand/mxc_nand.c +2 -0

+
+#ifdef MXC_NFC_V1_1
 static int mxc_nand_read_oob_syndrome(struct mtd_info *mtd,
 				      struct nand_chip *chip,
 				      int page, int sndcmd)

@@ -1235,15 +1235,11 @@ int board_nand_init(struct nand_chip *this)
 	host->pagesize_2k = 0;
 

drivers/mtd/nand/mxc_nand.c int board_nand_init(struct nand_chip *this) · line 1238

Quoted 5 lines

drivers/mtd/nand/mxc_nand.c +1 -3

 	this->ecc.size = 512;
-	tmp = readw(&host->regs->config1);
-	tmp |= NFC_ECC_EN;
-	writew(tmp, &host->regs->config1);
+	_mxc_nand_enable_hwecc(mtd, 1);

...but you are calling it after removing the code in the init function,
and I do not understand how ECC is enabled.

There is no reason to have board configs to select the NFC IP revision. Just let the driver detect it. BTW, remove broken NFC IP revision configs from board config files.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---

 .../include/configs/flea3.h                        |    1 -
 .../include/configs/mx35pdk.h                      |    1 -
 .../include/configs/tx25.h                         |    1 -
 .../include/fsl_nfc.h                              |    8 +++-----
 4 files changed, 3 insertions(+), 8 deletions(-)

include/configs/flea3.h +0 -1

index 46939d4..43cadbc 100644
@@ -221,7 +221,6 @@
  * NAND FLASH driver setup
  */
 #define CONFIG_NAND_MXC
-#define CONFIG_NAND_MXC_V1_1
 #define CONFIG_MXC_NAND_REGS_BASE	(NFC_BASE_ADDR)
 #define CONFIG_SYS_MAX_NAND_DEVICE	1
 #define CONFIG_SYS_NAND_BASE		(NFC_BASE_ADDR)

include/configs/mx35pdk.h +0 -1

index 6eb5da5..93a9dd7 100644
@@ -239,7 +239,6 @@
  * NAND FLASH driver setup
  */
 #define CONFIG_NAND_MXC
-#define CONFIG_NAND_MXC_V1_1
 #define CONFIG_MXC_NAND_REGS_BASE	(NFC_BASE_ADDR)
 #define CONFIG_SYS_MAX_NAND_DEVICE	1
 #define CONFIG_SYS_NAND_BASE		(NFC_BASE_ADDR)

include/configs/tx25.h +0 -1

index 6821528..870e863 100644
@@ -108,7 +108,6 @@
 
 /* NAND */
 #define CONFIG_NAND_MXC
-#define CONFIG_NAND_MXC_V1_1
 #define CONFIG_MXC_NAND_REGS_BASE	(0xBB000000)
 #define CONFIG_SYS_MAX_NAND_DEVICE	1
 #define CONFIG_SYS_NAND_BASE		(0xBB000000)

include/fsl_nfc.h +3 -2

index c248cef..6618089 100644
@@ -42,10 +42,12 @@
  */
 #if defined(CONFIG_MX27) || defined(CONFIG_MX31)
 #define MXC_NFC_V1
+#define is_mxc_nfc_11()		0
 #elif defined(CONFIG_MX25) || defined(CONFIG_MX35)
 #define MXC_NFC_V1_1
+#define is_mxc_nfc_11()		1
 #else
-#warning "MXC NFC version not defined"
+#error "MXC NFC implementation not supported"
 #endif
 
 #if defined(MXC_NFC_V1)

@@ -53,14 +55,10 @@
 #define NAND_MXC_SPARE_BUF_SIZE		16
 #define NAND_MXC_REG_OFFSET		0xe00
 #define NAND_MXC_2K_MULTI_CYCLE
-#define is_mxc_nfc_11()			0

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
  .../arch/arm/include/asm/arch-mx5/imx-regs.h       |    9 +
  .../drivers/mtd/nand/mxc_nand.c                    |  217 +++++++++++++++-----
  .../include/fsl_nfc.h                              |  149 +++++++++-----
  .../nand_spl/nand_boot_fsl_nfc.c                   |  114 +++++++---
  4 files changed, 363 insertions(+), 126 deletions(-)

arch/arm/include/asm/arch-mx5/imx-regs.h +0 -0

index 7f66b61..55e9660 100644
@@ -232,6 +232,15 @@
  #define CS0_32M_CS1_32M_CS2_32M_CS3_32M		3
 

Quoted 24 lines · Beno?t Th?baudeau

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
  .../arch/arm/include/asm/arch-mx5/imx-regs.h       |    9 +
  .../drivers/mtd/nand/mxc_nand.c                    |  217 
+++++++++++++++-----
  .../include/fsl_nfc.h                              |  149 
+++++++++-----
  .../nand_spl/nand_boot_fsl_nfc.c                   |  114 +++++++---
  4 files changed, 363 insertions(+), 126 deletions(-)

(quoted diff) +0 -0

u-boot-4d3c95f.orig/arch/arm/include/asm/arch-mx5/imx-regs.h u-boot-4d3c95f/arch/arm/include/asm/arch-mx5/imx-regs.h index 7f66b61..55e9660 100644

arch/arm/include/asm/arch-mx5/imx-regs.h +3 -0

@@ -232,6 +232,15 @@
  #define CS0_32M_CS1_32M_CS2_32M_CS3_32M        3
    /*
+ * SRC register definitions
+ */
+#if defined(CONFIG_MX51)

arch/arm/include/asm/arch-mx5/imx-regs.h

Quoted 6 lines

arch/arm/include/asm/arch-mx5/imx-regs.h +5 -0

+#define SRC_SBMR_NF16B        (1 << 2)
+#elif defined(CONFIG_MX53)
+#define SRC_SBMR_NF16B        (1 << 13)
+#endif
+
 

You could give an error if a multi-platform kernel has both defined, if a run-time check is too difficult.

nand_spl/nand_boot_fsl_nfc.c +0 -0

index a40c998..1096727 100644

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
Changes for v2:
- Fix warning for unused tmp variable in board_nand_init() for NFC V1.

 .../arch/arm/include/asm/arch-mx5/imx-regs.h       |    9 +
 .../drivers/mtd/nand/mxc_nand.c                    |  219 +++++++++++++++-----
 .../include/fsl_nfc.h                              |  149 ++++++++-----
 .../nand_spl/nand_boot_fsl_nfc.c                   |  114 +++++++---
 4 files changed, 365 insertions(+), 126 deletions(-)

Quoted 6 lines · Beno?t Th?baudeau

Signed-off-by: Beno?t Th?baudeau <[email protected]> Cc: Scott Wood <[email protected]> Cc: Stefano Babic <[email protected]> --- Changes for v2: - Fix warning for unused tmp variable in board_nand_init() for NFC V1.

Quoted 6 lines

.../arch/arm/include/asm/arch-mx5/imx-regs.h | 9 +
.../drivers/mtd/nand/mxc_nand.c | 219
+++++++++++++++----- .../include/fsl_nfc.h

|  149 ++++++++----- .../nand_spl/nand_boot_fsl_nfc.c
|  114 +++++++--- 4 files changed, 365 insertions(+), 126

deletions(-)

Unless Tom or Wolfgang object, I'm inclined to drop the objection to adding new hardware support to nand_spl in this case. I'd rather see the support be merged rather than ignored because a contributor has time for a small job but not a large one. Plus, this code will likely be reused by the new SPL support, if this platform is space constrained, so it's not dead-end effort.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 14 lines · Scott Wood

Quoted 6 lines · Beno?t Th?baudeau

Signed-off-by: Beno?t Th?baudeau <[email protected]> Cc: Scott Wood <[email protected]> Cc: Stefano Babic <[email protected]> --- Changes for v2: - Fix warning for unused tmp variable in board_nand_init() for NFC V1.

Quoted 6 lines

.../arch/arm/include/asm/arch-mx5/imx-regs.h | 9 +
.../drivers/mtd/nand/mxc_nand.c | 219
+++++++++++++++----- .../include/fsl_nfc.h

|  149 ++++++++----- .../nand_spl/nand_boot_fsl_nfc.c
|  114 +++++++--- 4 files changed, 365 insertions(+), 126

deletions(-)

Quoted 6 lines

Unless Tom or Wolfgang object, I'm inclined to drop the objection to adding new hardware support to nand_spl in this case. I'd rather see the support be merged rather than ignored because a contributor has time for a small job but not a large one. Plus, this code will likely be reused by the new SPL support, if this platform is space constrained, so it's not dead-end effort.

I'm OK with pulling this in while providing an on-the-record prod to please find some time to do a conversion or two in time for v2013.01.

Quoted 26 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 21 lines · Scott Wood

Quoted 6 lines · Beno?t Th?baudeau

Signed-off-by: Beno?t Th?baudeau <[email protected]> Cc: Scott Wood <[email protected]> Cc: Stefano Babic <[email protected]> --- Changes for v2: - Fix warning for unused tmp variable in board_nand_init() for NFC V1.

Quoted 6 lines

.../arch/arm/include/asm/arch-mx5/imx-regs.h | 9 +
.../drivers/mtd/nand/mxc_nand.c | 219
+++++++++++++++----- .../include/fsl_nfc.h

|  149 ++++++++----- .../nand_spl/nand_boot_fsl_nfc.c
|  114 +++++++--- 4 files changed, 365 insertions(+), 126

deletions(-)

Unless Tom or Wolfgang object, I'm inclined to drop the objection to adding new hardware support to nand_spl in this case. I'd rather see the support be merged rather than ignored because a contributor has time for a small job but not a large one. Plus, this code will likely be reused by the new SPL support, if this platform is space constrained, so it's not dead-end effort.

Quoted 4 lines

I'm OK with pulling this in while providing an on-the-record prod to
please find some time to do a conversion or two in time for v2013.01.

I'm going to leave this one until there's a config added that uses it,
so that we at least get compile-testing.

The EFIKA MX Smartbook probably has MLC if we consider its NAND size. 4-kiB
pages should be supported by nand_spl/nand_boot_fsl_nfc.c, but not yet by

drivers/mtd/nand/mxc_nand.c. The latter currently has a CONFIG_SYS_NAND_LARGEPAGE to differentiate 512-B and 2-kiB pages. If we were to
add support for 4-kiB pages to this driver, I think that this should be
replaced with a CONFIG_SYS_NAND_PAGE_SIZE like in nand_boot_fsl_nfc.c. Do you
agree?

Quoted 4 lines · Beno?t Th?baudeau

The EFIKA MX Smartbook probably has MLC if we consider its NAND size. 4-kiB
pages should be supported by nand_spl/nand_boot_fsl_nfc.c, but not yet by

Quoted 8 lines

drivers/mtd/nand/mxc_nand.c. The latter currently has a CONFIG_SYS_NAND_LARGEPAGE to differentiate 512-B and 2-kiB pages. If we were to
add support for 4-kiB pages to this driver, I think that this should be
replaced with a CONFIG_SYS_NAND_PAGE_SIZE like in nand_boot_fsl_nfc.c. Do you
agree?

Yes.

Hi Scott,

Quoted 30 lines · Scott Wood

Quoted 29 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 24 lines · Scott Wood

Quoted 7 lines · Beno?t Th?baudeau

Signed-off-by: Beno?t Th?baudeau <[email protected]> Cc: Scott Wood <[email protected]> Cc: Stefano Babic <[email protected]>
---
Changes for v2: - Fix warning for unused tmp variable in board_nand_init() for NFC V1.

Quoted 6 lines

.../arch/arm/include/asm/arch-mx5/imx-regs.h | 9 +
.../drivers/mtd/nand/mxc_nand.c | 219
+++++++++++++++----- .../include/fsl_nfc.h

|  149 ++++++++----- .../nand_spl/nand_boot_fsl_nfc.c
|  114 +++++++--- 4 files changed, 365 insertions(+), 126

deletions(-)

Unless Tom or Wolfgang object, I'm inclined to drop the objection
to adding new hardware support to nand_spl in this case. I'd rather see the support be merged rather than ignored because a contributor has time for a small job but not a large one.
Plus,
this code will likely be reused by the new SPL support, if this platform is space constrained, so it's not dead-end effort.

Quoted 8 lines

Quoted 4 lines

I'm OK with pulling this in while providing an on-the-record prod to
please find some time to do a conversion or two in time for v2013.01.

I'm going to leave this one until there's a config added that uses it,
so that we at least get compile-testing.

OK.

I won't be able to add my i.MX51 board to mainline before at least a few months.

It's hard to find the schematics of all the i.MX5 boards supported by mainline
U-Boot. According to the links below, at least the Genesi EFIKA MX Smartbook and
the Freescale MX53 ARD boards have embedded NAND. Matt, Fabio, is it possible to
find the schematics of these boards somewhere?
http://www.genesi-tech.com/products/smartbook
https://community.freescale.com/thread/289468

The EFIKA MX Smartbook probably has MLC if we consider its NAND size. 4-kiB
pages should be supported by nand_spl/nand_boot_fsl_nfc.c, but not yet by
drivers/mtd/nand/mxc_nand.c. The latter currently has a CONFIG_SYS_NAND_LARGEPAGE to differentiate 512-B and 2-kiB pages. If we were to
add support for 4-kiB pages to this driver, I think that this should be
replaced with a CONFIG_SYS_NAND_PAGE_SIZE like in nand_boot_fsl_nfc.c. Do you
agree?

Also, I've noticed that some of the oobfree fields of the nand_ecclayout
structures in mxc_nand.c are slightly different from what can be found in Linux.
Any idea about which one is correct (if any)?

This field does not even always start at offset 0 when it looks free according
to the ECC info. Is this normal?

Quoted 5 lines · Beno?t Th?baudeau

Also, I've noticed that some of the oobfree fields of the nand_ecclayout
structures in mxc_nand.c are slightly different from what can be found in Linux.
Any idea about which one is correct (if any)?

Unless there's an obvious error such as overlap with ECC or a bad block
marker, there isn't really a right answer (except to the extent that you're wasting bytes) -- but it's important that everyone agree. So the answer is basically, "which compatibility would it hurt more to break?"

That said, the U-Boot ones make more sense to me in terms of not having
strange missing bytes.

Hi Scott,

Quoted 14 lines · Scott Wood

Quoted 5 lines · Beno?t Th?baudeau

Also, I've noticed that some of the oobfree fields of the nand_ecclayout
structures in mxc_nand.c are slightly different from what can be found in Linux.
Any idea about which one is correct (if any)?

Unless there's an obvious error such as overlap with ECC or a bad block
marker, there isn't really a right answer (except to the extent that you're wasting bytes) -- but it's important that everyone agree. So the answer is basically, "which compatibility would it hurt more to break?"

Quoted 3 lines

That said, the U-Boot ones make more sense to me in terms of not having
strange missing bytes.

I've just found this commit, which explains what's going on:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=8c1fd89a85f898384df02217c09c98c2f39b4832

Quoted 25 lines · Beno?t Th?baudeau

Hi Scott,

Quoted 21 lines · Scott Wood

Quoted 6 lines · Beno?t Th?baudeau

Also, I've noticed that some of the oobfree fields of the nand_ecclayout
structures in mxc_nand.c are slightly different from what can be
found in Linux.
Any idea about which one is correct (if any)?

Unless there's an obvious error such as overlap with ECC or a bad block
marker, there isn't really a right answer (except to the extent that
you're wasting bytes) -- but it's important that everyone agree.
So
the answer is basically, "which compatibility would it hurt more to
break?"

That said, the U-Boot ones make more sense to me in terms of not having
strange missing bytes.

Quoted 2 lines

I've just found this commit, which explains what's going on:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=8c1fd89a85f898384df02217c09c98c2f39b4832

I don't understand the bit about "on 16bit flashes it is on byte 11" --
I thought with 16-bit NAND the bad block marker was always at offset zero, even on small-page NAND.

It's hard to find the schematics of all the i.MX5 boards supported by mainline U-Boot. According to the links below, at least the Genesi EFIKA MX Smartbook and the Freescale MX53 ARD boards have embedded NAND. Matt, Fabio, is it possible to find the schematics of these boards somewhere?

Quoted 1 line · Beno?t Th?baudeau

It's hard to find the schematics of all the i.MX5 boards supported by

mainline

Quoted 1 line

U-Boot. According to the links below, at least the Genesi EFIKA MX

Smartbook and

Quoted 1 line

the Freescale MX53 ARD boards have embedded NAND. Matt, Fabio, is it

possible to

Quoted 1 line

find the schematics of these boards somewhere?

Yes, will send you offline.

Regards,

Fabio Estevam
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
Changes for v2:
- Fix warning for unused tmp variable in board_nand_init() for NFC V1.

 .../arch/arm/include/asm/arch-mx5/imx-regs.h       |    9 +
 .../drivers/mtd/nand/mxc_nand.c                    |  219 +++++++++++++++-----
 .../include/fsl_nfc.h                              |  149 ++++++++-----
 .../nand_spl/nand_boot_fsl_nfc.c                   |  114 +++++++---
 4 files changed, 365 insertions(+), 126 deletions(-)

Quoted 8 lines · Beno?t Th?baudeau

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Scott Wood <[email protected]>

Cc Stefano Babic <[email protected]>

---
Changes for v2:
- Fix warning for unused tmp variable in board_nand_init() for NFC V1.

Quoted 8 lines

 .../arch/arm/include/asm/arch-mx5/imx-regs.h       |    9 +
 .../drivers/mtd/nand/mxc_nand.c                    |  219
 +++++++++++++++-----
 .../include/fsl_nfc.h                              |  149
 ++++++++-----
 .../nand_spl/nand_boot_fsl_nfc.c                   |  114
 +++++++---
 4 files changed, 365 insertions(+), 126 deletions(-)

Is there a board that uses this?

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl drivers. It also fixes several issues and cleans up the code a little bit.

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl drivers. It also fixes several issues and cleans up the code a little bit.

Best regards,
Beno?t

Dear Beno?t Th?baudeau,

Quoted 7 lines

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl
drivers. It also fixes several issues and cleans up the code a little bit.

Quoted 2 lines

Best regards,
Beno?t

Did this patchset advance any further? Any chance we can see this applied?
Anything I can help with to make it applied?

Dear Marek Vasut,

Quoted 12 lines · Marek Vasut

Dear Beno?t Th?baudeau,

Quoted 9 lines

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl
drivers. It also fixes several issues and cleans up the code a little bit.

Best regards,
Beno?t

Quoted 3 lines

Did this patchset advance any further? Any chance we can see this applied?
Anything I can help with to make it applied?

Only 13/13 has not yet been applied. I still have to add NFC support to one i.MX5 board for the patch to be accepted. Fabio has confirmed that mx53ard would be fine.

Fabio, can you give me the reference of the NAND Flash that you will use for testing on i.MX53? That will allow me to adjust the NFC clock and to know if I also have to add support for 4-kiB pages or multi-CS.

Marek, I hope to find some time soon to finish this, but if you can work on the remaining tasks, that's also fine with me. Thanks.

Best regards,
Beno?t

Dear Beno?t Th?baudeau,

Quoted 19 lines

Dear Marek Vasut,

Quoted 15 lines · Marek Vasut

Dear Beno?t Th?baudeau,

Quoted 9 lines

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl
drivers. It also fixes several issues and cleans up the code a little bit.

Best regards,
Beno?t

Did this patchset advance any further? Any chance we can see this applied?
Anything I can help with to make it applied?

Quoted 1 line

Only 13/13 has not yet been applied. I still have to add NFC

support to one

Quoted 1 line

i.MX5 board for the patch to be accepted. Fabio has confirmed that

mx53ard

Quoted 1 line

would be fine.

Sigh ... I have board with NAND pending, so Scott, please apply.

Quoted 27 lines

Dear Beno?t Th?baudeau,

Quoted 12 lines

Dear Marek Vasut,

Quoted 9 lines · Marek Vasut

Dear Beno?t Th?baudeau,

Quoted 7 lines

Hi all,

This series aims at adding support for i.MX5 to the mxc nand mtd and spl
drivers. It also fixes several issues and cleans up the code a little bit.

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Best regards,
Beno?t

Did this patchset advance any further? Any chance we can see this applied?
Anything I can help with to make it applied?

Only 13/13 has not yet been applied. I still have to add NFC

support to one

Quoted 1 line

i.MX5 board for the patch to be accepted. Fabio has confirmed that

Quoted 5 lines

mx53ard

Quoted 1 line

would be fine.

Sigh ... I have board with NAND pending, so Scott, please apply.

Can you repost it as part of a patchset with that board, and I'll ack so they can go together?

Does this board do NAND boot?

If so, new-SPL rather than nand_spl
would be nice. Tom's comment at the time was, "I'm OK with pulling this in while providing an on-the-record prod to please find some time to do a conversion or two in time for v2013.01." If this patch is applied now, it would be for the release after v2013.01...

-Scott

Fabio, can you give me the reference of the NAND Flash that you will use for testing on i.MX53? That will allow me to adjust the NFC clock and to know if I also have to add support for 4-kiB pages or multi-CS.

Hi Beno?t,

On Mon, Jan 7, 2013 at 11:37 AM, Beno?t Th?baudeau

Quoted 3 lines · <[email protected]> wrote:

Fabio, can you give me the reference of the NAND Flash that you will use for testing on i.MX53? That will allow me to adjust the NFC clock and to know if I also have to add support for 4-kiB pages or multi-CS.

The NAND I have is a K9LAG08U0M.

Dear Fabio Estevam,

Quoted 11 lines

Hi Beno?t,

On Mon, Jan 7, 2013 at 11:37 AM, Beno?t Th?baudeau

Quoted 5 lines · <[email protected]> wrote:

Fabio, can you give me the reference of the NAND Flash that you will use
for testing on i.MX53? That will allow me to adjust the NFC clock and to
know if I also have to add support for 4-kiB pages or multi-CS.

Quoted 1 line

The NAND I have is a K9LAG08U0M.

Do you guys happen to have include/config/<config>.h section for the MX5 NFC ?
esp. this CONFIG_MXC_NAND_IP_REGS_BASE is what I don't quite get how it fits in.

#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR_AXI
#define CONFIG_NAND_MXC
#define CONFIG_MXC_NAND_REGS_BASE NFC_BASE_ADDR_AXI
#define CONFIG_MXC_NAND_IP_REGS_BASE NFC_BASE_ADDR
#define CONFIG_SYS_NAND_LARGEPAGE
#define CONFIG_MXC_NAND_HWECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT

Dear Marek Vasut,

Quoted 13 lines · Marek Vasut

Dear Fabio Estevam,

Quoted 11 lines

Hi Beno?t,

On Mon, Jan 7, 2013 at 11:37 AM, Beno?t Th?baudeau

Quoted 5 lines · <[email protected]> wrote:

Fabio, can you give me the reference of the NAND Flash that you will use
for testing on i.MX53? That will allow me to adjust the NFC clock and to
know if I also have to add support for 4-kiB pages or multi-CS.

Quoted 6 lines

Quoted 1 line

The NAND I have is a K9LAG08U0M.

Do you guys happen to have include/config/<config>.h section for the MX5 NFC ?
esp. this CONFIG_MXC_NAND_IP_REGS_BASE is what I don't quite get how it fits in.

Here is this section for my custom i.MX51 board:

#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR_AXI
#define CONFIG_NAND_MXC
#define CONFIG_MXC_NAND_REGS_BASE NFC_BASE_ADDR_AXI
#define CONFIG_MXC_NAND_IP_REGS_BASE NFC_BASE_ADDR
#define CONFIG_SYS_NAND_LARGEPAGE
#define CONFIG_MXC_NAND_HWECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT

Dear Beno?t Th?baudeau,

Quoted 30 lines

Dear Marek Vasut,

Quoted 16 lines · Marek Vasut

Dear Fabio Estevam,

Quoted 14 lines

Hi Beno?t,

On Mon, Jan 7, 2013 at 11:37 AM, Beno?t Th?baudeau

Quoted 8 lines · <[email protected]> wrote:

Fabio, can you give me the reference of the NAND Flash that you
will use
for testing on i.MX53? That will allow me to adjust the NFC clock
and to
know if I also have to add support for 4-kiB pages or multi-CS.

Quoted 8 lines

Quoted 1 line

The NAND I have is a K9LAG08U0M.

Do you guys happen to have include/config/<config>.h section for the
MX5 NFC ?
esp. this CONFIG_MXC_NAND_IP_REGS_BASE is what I don't quite get how
it fits in.

Here is this section for my custom i.MX51 board:

Quoted 8 lines

#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR_AXI
#define CONFIG_NAND_MXC
#define CONFIG_MXC_NAND_REGS_BASE NFC_BASE_ADDR_AXI
#define CONFIG_MXC_NAND_IP_REGS_BASE NFC_BASE_ADDR
#define CONFIG_SYS_NAND_LARGEPAGE
#define CONFIG_MXC_NAND_HWECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT

Benoit, not much luck with this stuff. Am I missing something else? I believe I
configured pinmux, I enabled the NAND clock too. But maybe there's something
else? Can you send me some patch that enables use of this NAND driver on your
MX5 platform?