In this patchset, a new i.MX35 board is added implementing

Signed-off-by Stefano Babic <[email protected]>

---
 drivers/mtd/nand/nand_ids.c |    2 ++
 1 file changed, 2 insertions(+)

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

index 3953549..fe75686 100644

Quoted 2 lines · Stefano Babic

Signed-off-by Stefano Babic <[email protected]>

---

Quoted 12 lines

 drivers/mtd/nand/nand_ids.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/mtd/nand/nand_ids.c +1 -0

index 3953549..fe75686 100644
@@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
 	/* 128 Gigabit */
 	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
 	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 3,3V 8-bit",	0x48, 4096, 16384, 0x100000,

drivers/mtd/nand/nand_ids.c const struct nand_flash_dev nand_flash_ids[] = { · line 138

Quoted 5 lines

drivers/mtd/nand/nand_ids.c +1 -0

+		LP_OPTIONS},
 	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
 	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
 

Why does this NAND chip need things specified that are zeroes for other chips?

Quoted 3 lines · Scott Wood

Quoted 2 lines · Stefano Babic

Signed-off-by Stefano Babic <[email protected]>

---

Hi Scott,

Quoted 12 lines

Quoted 12 lines

 drivers/mtd/nand/nand_ids.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/mtd/nand/nand_ids.c +1 -0

index 3953549..fe75686 100644
@@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
 	/* 128 Gigabit */
 	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
 	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 3,3V 8-bit",	0x48, 4096, 16384, 0x100000,

Quoted 8 lines

drivers/mtd/nand/nand_ids.c const struct nand_flash_dev nand_flash_ids[] = { · line 138

Quoted 5 lines

drivers/mtd/nand/nand_ids.c +1 -0

+		LP_OPTIONS},
 	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
 	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
 

Why does this NAND chip need things specified that are zeroes for other chips?

At least on this board with MX35, the chip cannot be recognized. Manufacturer ID and device ID are read flawlessly, but then u-boot fails to get the correct geometry. Setting explicitely the values, I can then read / write into the NAND without any problem. It can be more a problem related to the specific MXC NAND driver (mxc_nand.c).

Quoted 28 lines · Stefano Babic

Quoted 3 lines · Scott Wood

Quoted 2 lines · Stefano Babic

Signed-off-by Stefano Babic <[email protected]>

---

Hi Scott,

Quoted 12 lines

Quoted 12 lines

 drivers/mtd/nand/nand_ids.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/mtd/nand/nand_ids.c +1 -0

index 3953549..fe75686 100644
@@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
 	/* 128 Gigabit */
 	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
 	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 3,3V 8-bit",	0x48, 4096, 16384, 0x100000,

Quoted 8 lines

drivers/mtd/nand/nand_ids.c const struct nand_flash_dev nand_flash_ids[] = { · line 138

Quoted 5 lines

drivers/mtd/nand/nand_ids.c +1 -0

+		LP_OPTIONS},
 	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
 	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
 

Why does this NAND chip need things specified that are zeroes for other chips?

Quoted 5 lines

At least on this board with MX35, the chip cannot be recognized. Manufacturer ID and device ID are read flawlessly, but then u-boot fails to get the correct geometry. Setting explicitely the values, I can then read / write into the NAND without any problem. It can be more a problem related to the specific MXC NAND driver (mxc_nand.c).

It seems to me that the values returned by this flash cannot be interpreted in nand_get_flash_type().

The values returned from a READ-ID command with address 0x00 are:

	0x2C 0x48 0x04 0x4A 0xA5,

I can really get these values from the flash, so the MXC controller gets the correct data.

However, the code in nand_base.c (lines from 2718, so not-Samsung case) parses the answer setting the NAND as a 16-bit device, but this is really a 8bit device. I do not know the meaning of the answer, it is not described in the datasheet.

Quoted 38 lines

Quoted 22 lines

Quoted 13 lines

Quoted 13 lines

 drivers/mtd/nand/nand_ids.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/mtd/nand/nand_ids.c +1 -0

index 3953549..fe75686 100644
@@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
 	/* 128 Gigabit */
 	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
 	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 3,3V 8-bit",	0x48, 4096, 16384, 0x100000,

Quoted 8 lines

drivers/mtd/nand/nand_ids.c const struct nand_flash_dev nand_flash_ids[] = { · line 138

Quoted 5 lines

drivers/mtd/nand/nand_ids.c +1 -0

+		LP_OPTIONS},
 	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
 	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
 

Why does this NAND chip need things specified that are zeroes for other chips?

Quoted 5 lines

At least on this board with MX35, the chip cannot be recognized. Manufacturer ID and device ID are read flawlessly, but then u-boot fails to get the correct geometry. Setting explicitely the values, I can then read / write into the NAND without any problem. It can be more a problem related to the specific MXC NAND driver (mxc_nand.c).

It seems to me that the values returned by this flash cannot be interpreted in nand_get_flash_type().

The values returned from a READ-ID command with address 0x00 are:

	0x2C 0x48 0x04 0x4A 0xA5,

I can really get these values from the flash, so the MXC controller gets the correct data.

Quoted 4 lines

However, the code in nand_base.c (lines from 2718, so not-Samsung case) parses the answer setting the NAND as a 16-bit device, but this is really a 8bit device. I do not know the meaning of the answer, it is not described in the datasheet.

Does the datasheet say anything about what the ID data is supposed to look like and how to interpret it? I tried to download it and Micron shoved an NDA in my face.

What kind of chip is this? Is the datasheet publicly available?

These threads seem relevant:
http://patchwork.ozlabs.org/patch/60042/
http://old.nabble.com/-U-Boot--Add-new-NAND-flash-td29858370.html

Does the chip support ONFI?

Quoted 5 lines · Scott Wood

What kind of chip is this? Is the datasheet publicly available?

These threads seem relevant:
http://patchwork.ozlabs.org/patch/60042/
http://old.nabble.com/-U-Boot--Add-new-NAND-flash-td29858370.html

It is the same case, as I can see, with the same chip.

Quoted 1 line

Quoted 1 line

Does the chip support ONFI?

The chip supports ONFI, but it seems the i.MX driver does not. Quite as described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always sent with address 0, I do not know if we can convince the driver to send the address.

Quoted 10 lines · Stefano Babic

Quoted 5 lines · Scott Wood

What kind of chip is this? Is the datasheet publicly available?

These threads seem relevant:
http://patchwork.ozlabs.org/patch/60042/
http://old.nabble.com/-U-Boot--Add-new-NAND-flash-td29858370.html

It is the same case, as I can see, with the same chip.

Quoted 1 line

Quoted 6 lines

Quoted 1 line

Does the chip support ONFI?

The chip supports ONFI, but it seems the i.MX driver does not. Quite as described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always sent with address 0, I do not know if we can convince the driver to send the address.

How did Linux end up resolving this?

I think it'd be better to have the
Micron decoding logic from that patch, than to introduce a special addition to the ID table for this one chip, which might not be correct for all chips with that ID byte.

The chip supports ONFI, but it seems the i.MX driver does not. Quite as described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always sent with address 0, I do not know if we can convince the driver to send the address.

Hi Stefano,

Le Mon, 10 Sep 2012 14:09:21 +0200,
Stefano Babic <[email protected]> a ?crit :

Quoted 4 lines

The chip supports ONFI, but it seems the i.MX driver does not. Quite as described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always sent with address 0, I do not know if we can convince the driver to send the address.

to add ONFI support to i.MX's driver, you can check this patch (in barebox, a similar patch for Linux is cooking, actually tested on i.MX53 and i.MX25) :
http://git.pengutronix.de/?p=barebox.git;a=commit;h=632c45795065e6a7471ab82be38e808eb6204341

arch/arm/cpu/arm1136/mx35/generic.c +8 -0

+#define RCSR_MEM_CTL_WEIM	0
+#define RCSR_MEM_CTL_NAND	1
+#define RCSR_MEM_CTL_SD		2
+#define RCSR_MEM_TYPE_NOR	0
+#define RCSR_MEM_TYPE_ONENAND	2
+#define RCSR_MEM_TYPE_SD	0
+#define RCSR_MEM_TYPE_I2C	2
+#define RCSR_MEM_TYPE_SPI	3

arch/arm/cpu/arm1136/mx35/generic.c +29 -0

+
+	u32 rcsr = readl(&ccm->rcsr);
+	u32 mem_type, mem_ctl;
+
+	/* In external mode, no boot device is returned */
+	if ((rcsr >> 10) & 0x03)
+		return BOOT_DEVICE_NONE;
+
+	mem_ctl = (rcsr >> 25) & 0x03;
+	mem_type = (rcsr >> 23) & 0x03;
+
+	switch (mem_ctl) {
+	case RCSR_MEM_CTL_WEIM:
+		switch (mem_type) {
+		case RCSR_MEM_TYPE_NOR:
+			return BOOT_DEVICE_NOR;
+		case RCSR_MEM_TYPE_ONENAND:
+			return BOOT_DEVICE_ONE_NAND;
+		default:
+			return BOOT_DEVICE_NONE;
+		}
+	case RCSR_MEM_CTL_NAND:
+		return BOOT_DEVICE_NAND;
+	case RCSR_MEM_CTL_SD:
+		switch (mem_type) {
+		case RCSR_MEM_TYPE_SD:
+			return BOOT_DEVICE_MMC1;
+		case RCSR_MEM_TYPE_I2C:
+			return BOOT_DEVICE_I2C;

Hi Stefano,

Le Thu, 6 Sep 2012 10:04:57 +0200,
Stefano Babic <[email protected]> a ?crit :

Quoted 8 lines

arch/arm/cpu/arm1136/mx35/generic.c +8 -0

+#define RCSR_MEM_CTL_WEIM	0
+#define RCSR_MEM_CTL_NAND	1
+#define RCSR_MEM_CTL_SD		2
+#define RCSR_MEM_TYPE_NOR	0
+#define RCSR_MEM_TYPE_ONENAND	2
+#define RCSR_MEM_TYPE_SD	0
+#define RCSR_MEM_TYPE_I2C	2
+#define RCSR_MEM_TYPE_SPI	3

arch/arm/cpu/arm1136/mx35/generic.c void reset_cpu(ulong addr) · line 510

Quoted 10 lines

arch/arm/cpu/arm1136/mx35/generic.c +10 -0

+
+u32 spl_boot_device(void)
+{
+	puts("spl_boot_device\n");
+	struct ccm_regs *ccm =
+		(struct ccm_regs *)IMX_CCM_BASE;
+
+#if 1
+	return BOOT_DEVICE_MMC1;
+#endif

thisseems not clean and seems caused by the fact that the define RCSR_MEM_CTL_SD should be 3 and not 2 so in your tests the function spl_boot_device was not detecting the right boot mode. Also IMHO this define should be named RCSR_MEM_CTL_EXPANSION as in the app note AN3996 at end of page 3 (there is a typo in the reference manual which seems to be a copy'n paste from i.MX25 as it doesn't take in acount the ATA HDD case) :
http://cache.freescale.com/files/dsp/doc/app_note/AN3996.pdf

Signed-off-by Stefano Babic <[email protected]>

---
 spl/Makefile |    6 ++++++
 1 file changed, 6 insertions(+)

spl/Makefile +0 -0

index f96c08e..77fc405 100644
@@ -109,6 +109,12 @@ $(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
 		-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
 endif

Quoted 21 lines · Stefano Babic

Signed-off-by Stefano Babic <[email protected]>

---
 spl/Makefile |    6 ++++++
 1 file changed, 6 insertions(+)

spl/Makefile +6 -0

index f96c08e..77fc405 100644
@@ -109,6 +109,12 @@ $(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
 		-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
 endif
 
+ifneq ($(CONFIG_IMX_CONFIG),)
+$(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
+	$(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T imximage \
+		-e $(CONFIG_SPL_TEXT_BASE) -d $< $@
+endif
+
 ALL-y	+= $(obj)u-boot-spl.bin
 

spl/Makefile $(OBJTREE)/MLO: $(obj)u-boot-spl.bin · line 120

Quoted 1 line

spl/Makefile +0 -0

 ifdef CONFIG_SAMSUNG

Is that really the name you want? MLO comes from some part or another (I've read it, just can't recall off-hand) of the IT ROM docs saying it will read a file named MLO.

Is mx35 in the same boat?
Or just looking
for a common name?

Quoted 22 lines · Tom Rini

Quoted 21 lines · Stefano Babic

Signed-off-by Stefano Babic <[email protected]>

---
 spl/Makefile |    6 ++++++
 1 file changed, 6 insertions(+)

spl/Makefile +6 -0

index f96c08e..77fc405 100644
@@ -109,6 +109,12 @@ $(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
 		-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
 endif
 
+ifneq ($(CONFIG_IMX_CONFIG),)
+$(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
+	$(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T imximage \
+		-e $(CONFIG_SPL_TEXT_BASE) -d $< $@
+endif
+
 ALL-y	+= $(obj)u-boot-spl.bin
 

Quoted 5 lines

spl/Makefile $(OBJTREE)/MLO: $(obj)u-boot-spl.bin · line 120

Quoted 1 line

spl/Makefile +0 -0

 ifdef CONFIG_SAMSUNG

Is that really the name you want? MLO comes from some part or another (I've read it, just can't recall off-hand) of the IT ROM docs saying it will read a file named MLO.

I know...

Quoted 3 lines

Is mx35 in the same boat?
Or just looking
for a common name?

Right. It makes no sense that the binary for Freescale's SOCs has a name, for TI another one, for...we can generates less confusion if we uses the same name.

Quoted 35 lines · Tom Rini

Quoted 22 lines · Stefano Babic

Quoted 21 lines

Signed-off-by Stefano Babic <[email protected]>

---
 spl/Makefile |    6 ++++++
 1 file changed, 6 insertions(+)

spl/Makefile +6 -0

index f96c08e..77fc405 100644
@@ -109,6 +109,12 @@ $(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
 		-a $(CONFIG_SPL_TEXT_BASE) -d $< $@
 endif
 
+ifneq ($(CONFIG_IMX_CONFIG),)
+$(OBJTREE)/MLO:	$(obj)u-boot-spl.bin
+	$(OBJTREE)/tools/mkimage -n  $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T imximage \
+		-e $(CONFIG_SPL_TEXT_BASE) -d $< $@
+endif
+
 ALL-y	+= $(obj)u-boot-spl.bin
 

Quoted 5 lines

spl/Makefile $(OBJTREE)/MLO: $(obj)u-boot-spl.bin · line 120

Quoted 1 line

spl/Makefile +0 -0

 ifdef CONFIG_SAMSUNG

Is that really the name you want? MLO comes from some part or another (I've read it, just can3't recall off-hand) of the IT ROM docs saying it will read a file named MLO.

I know...

Quoted 3 lines

Is mx35 in the same boat?
Or just looking
for a common name?

Quoted 3 lines

Right. It makes no sense that the binary for Freescale's SOCs has a name, for TI another one, for...we can generates less confusion if we uses the same name.

Agreed. I guess what I'm asking is, in the TI case the ROM reads FAT and must find 'MLO'. Does mx35 do the same or

is the post-build step
"dd if=MLO of=/dev/... ..." and the filename doesn't matter?

I'm fine
with the change now, just looking for the full details. Thanks!

Quoted 2 lines

Agreed. I guess what I'm asking is, in the TI case the ROM reads FAT and must find 'MLO'. Does mx35 do the same or

No. And not only the MX35, but also the MX5/MX6.

Quoted 2 lines

is the post-build step
"dd if=MLO of=/dev/... ..." and the filename doesn't matter?

Exactly. The ROM does not understand a filesystem, and the SPL must be stored at a fixed address in the SD card. The filename does not matter, and the SPL is not seen as file, but as a raw image.

Quoted 2 lines

I'm fine
with the change now, just looking for the full details. Thanks!

As for Freescale the filename does not matter while for TI does, we can use for both MLO ;-)

Hello,

Quoted 9 lines

Exactly. The ROM does not understand a filesystem, and the SPL must be stored at a fixed address in the SD card. The filename does not matter, and the SPL is not seen as file, but as a raw image.

Quoted 2 lines

I'm fine
with the change now, just looking for the full details. Thanks!

As for Freescale the filename does not matter while for TI does, we can use for both MLO ;-)

Then in that case I would precisely *not* use the same filename, in order to make it clear that Freescale SPL cannot be used in the same way as the TI SPL. Naming it MLO will certainly confuse users having previous experience with TI stuff: it will lead them to believe that creating a FAT filesystem and putting the MLO file in it will be the necessary steps to get this SPL loaded by the ROM code.

Quoted 2 lines · Thomas Petazzoni

Hello,

Hi Thomas,

Quoted 10 lines

Quoted 9 lines

Exactly. The ROM does not understand a filesystem, and the SPL must be stored at a fixed address in the SD card. The filename does not matter, and the SPL is not seen as file, but as a raw image.

Quoted 2 lines

I'm fine
with the change now, just looking for the full details. Thanks!

As for Freescale the filename does not matter while for TI does, we can use for both MLO ;-)

Quoted 6 lines

Then in that case I would precisely *not* use the same filename, in order to make it clear that Freescale SPL cannot be used in the same way as the TI SPL. Naming it MLO will certainly confuse users having previous experience with TI stuff: it will lead them to believe that creating a FAT filesystem and putting the MLO file in it will be the necessary steps to get this SPL loaded by the ROM code.

Of couse, setting a common name is not a reason enough for the users to not read the manual ;-). The way TI and Freescale have chosen to boot their SOCs are and remain quite differently.

The reason to have a common name is to avoid to document for each SOC which is the binary result. Maybe a more neutral name as "SPL" instead of "MLO" ? This is the first attempt to set SPL for a not-TI SOC, but hopefully other SOCs will follow, and it is better to set already some simple rules,

In any case, the resulting binary is a different thing as how to put the binary into the target: SPL can be copied as MLO on the SD-Card. Tom, what do you think ?