Sunxi NAND support for U-Boot

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/Makefile       |   2 +-
 drivers/mtd/nand/nand_timings.c | 252 
++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h        |   3 +
 3 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/nand_timings.c

Quoted 10 lines

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
  drivers/mtd/nand/Makefile       |   2 +-
  drivers/mtd/nand/nand_timings.c | 252
++++++++++++++++++++++++++++++++++++++++
  include/linux/mtd/nand.h        |   3 +
  3 files changed, 256 insertions(+), 1 deletion(-)

create mode 100644 drivers/mtd/nand/nand_timings.c

This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from.

It would probably be better to handle this as part of a general sync with the Linux mtd code.

-Scott

Hello Scott et al.,

Op 06-06-15 om 00:02 schreef Scott Wood:

On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote:

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/Makefile       |   2 +-
 drivers/mtd/nand/nand_timings.c | 252
++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h        |   3 +
 3 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/nand_timings.c

This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from.

Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1] and contains work
that was not yet brought upstream, yet is required for NAND on sunxi to work.

It would probably be better to handle this as part of a general sync with the Linux mtd code.

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)
- Randomisation support (patch 6)
- Per-partition settings for ECC and randomisation (left out of my RFC, highly desirable
but not strictly required for U-boot booting)

Quoted 30 lines

Hello Scott et al.,

Op 06-06-15 om 00:02 schreef Scott Wood:

On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote:

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
  drivers/mtd/nand/Makefile       |   2 +-
  drivers/mtd/nand/nand_timings.c | 252
++++++++++++++++++++++++++++++++++++++++
  include/linux/mtd/nand.h        |   3 +
  3 files changed, 256 insertions(+), 1 deletion(-)

create mode 100644 drivers/mtd/nand/nand_timings.c

This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from.

Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1] and contains work
that was not yet brought upstream, yet is required for NAND on sunxi to work.

It would probably be better to handle this as part of a general sync with the Linux mtd code.

Quoted 8 lines

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)
- Randomisation support (patch 6)
- Per-partition settings for ECC and randomisation (left out of my RFC, highly desirable
but not strictly required for U-boot booting)

Hello,

as I understand it the ECC and randomisation settings for the bootloader part of the nand are suboptimal or unusable for ubifs so if u-boot SPL is to read the u-boot binary and later u-boot the kernel from an ubifs volume it has to support non-uniform settings. Alternatively the bootloader part can be extended to contain partitions for u-boot binary and kernel image written to raw partition without filesystem much like what Andriod usually does.

Thanks

Michal

Hello Michal,

Op 08-06-15 om 10:34 schreef Michal Suchanek:

Quoted 41 lines · Roy Spliet

Quoted 30 lines

Hello Scott et al.,

Op 06-06-15 om 00:02 schreef Scott Wood:

On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote:

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
  drivers/mtd/nand/Makefile       |   2 +-
  drivers/mtd/nand/nand_timings.c | 252
++++++++++++++++++++++++++++++++++++++++
  include/linux/mtd/nand.h        |   3 +
  3 files changed, 256 insertions(+), 1 deletion(-)

create mode 100644 drivers/mtd/nand/nand_timings.c

This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from.

Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1] and contains work
that was not yet brought upstream, yet is required for NAND on sunxi to work.

It would probably be better to handle this as part of a general sync with the Linux mtd code.

Quoted 8 lines

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)
- Randomisation support (patch 6)
- Per-partition settings for ECC and randomisation (left out of my RFC, highly desirable
but not strictly required for U-boot booting)

Hello,

Quoted 7 lines

as I understand it the ECC and randomisation settings for the bootloader part of the nand are suboptimal or unusable for ubifs so if u-boot SPL is to read the u-boot binary and later u-boot the kernel from an ubifs volume it has to support non-uniform settings. Alternatively the bootloader part can be extended to contain partitions for u-boot binary and kernel image written to raw partition without filesystem much like what Andriod usually does.

SPL does not read U-boot from UBI. The SPL driver is separate, much smaller and
only reads in the same way BROM does. U-boot itself is not bound by the limitations
imposed by BROM, which means proper randomisation and ECC settings can be used
for "the UBI partition".

Hello Scott et al.,

Op 06-06-15 om 00:02 schreef Scott Wood:

Quoted 11 lines · Roy Spliet

Quoted 10 lines

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/Makefile       |   2 +-
 drivers/mtd/nand/nand_timings.c | 252 
++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h        |   3 +
 3 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/nand_timings.c

Quoted 4 lines

This code comes from Linux and yet I see no acknowledgement of that,
much less a statement of which version of Linux this was pulled from.

Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1] and contains work
that was not yet brought upstream, yet is required for NAND on sunxi to work.

Quoted 3 lines

It would probably be better to handle this as part of a general sync
with the Linux mtd code.

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)

U-Boot has the additional challenge
- Partitioning is not done the upstream way, but rather in/around cmd_mtdparts

We started discussion on these topics in the #mtd IRC channel (OFTC), and several ideas
have come up. The way I see it these issues can currently either be addressed by
bolting/duct-taping/tie-wrapping more layers of indirection on top of upstream MTD
framework, but really I feel that it might require a bit more of a structural approach
that may or may not break existing drivers.
The code I posted as RFC is functional. If you wish to steer towards an MTD sync-up, I

highly suggest first getting these issues tackled, and then making sure that we extend
the U-boot side of MTD with OF support for everything. This trajectory should include
deprecating the current implementation of cmd_mtdparts and hook that command up
to the "new" upstream way. In other words: now is probably not the right moment.

Quoted 6 lines

Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1] and contains work
that was not yet brought upstream, yet is required for NAND on sunxi to work.

Quoted 7 lines

Quoted 3 lines

It would probably be better to handle this as part of a general sync
with the Linux mtd code.

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)

Patches 1-3 are already in Linux (if there are subtle differences needed those should be followup patches, with an explanation of why it needs to differ from Linux), except that patch 3 for some reason has "onfi_timing_mode_ds" where Linux has "onfi_timing_mode_default".

I will try to do a sync soon.

Hi Scott,

On June 8, 2015, 8:24 p.m., Scott Wood wrote:

<snip>

Quoted 1 line

Quoted 1 line

Correct, my apologies as I should have clarified that "work by

Boris

Quoted 2 lines

Quoted 2 lines

Brezillon" does not
mean "upsteam work". The code comes from Boris' github tree[1]

and

Quoted 2 lines

Quoted 2 lines

contains work
that was not yet brought upstream, yet is required for NAND on

sunxi

Quoted 11 lines

Quoted 8 lines

to work.

Quoted 3 lines

It would probably be better to handle this as part of a general sync
with the Linux mtd code.

Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown
by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)

Patches 1-3 are already in Linux (if there are subtle differences needed those should be followup patches, with an explanation of

why it

Quoted 1 line

needs to differ from Linux), except that patch 3 for some reason

has

Quoted 2 lines

"onfi_timing_mode_ds" where Linux has "onfi_timing_mode_default".

Quoted 1 line

I will try to do a sync soon.

If you could do that that would be great, that should at least shrink the size of this patch-set by 3 patches.

I assume that you will not be sending a pull-req for this sync for v2015.07,

if you can make a git branch with the sync available
somewhere for us to build on top of, then that would be great.

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/nand_base.c | 1 +
 include/linux/mtd/nand.h     | 7 +++++++
 2 files changed, 8 insertions(+)

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

index c0e381a..dbeb092 100644
@@ -3709,6 +3709,7 @@ static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
 		chip->options |= type->options;
 		chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
 		chip->ecc_step_ds = NAND_ECC_STEP(type);
+		chip->onfi_timing_mode_ds = type->onfi_timing_mode_ds;
 
 		*busw = type->options & NAND_BUSWIDTH_16;
 

include/linux/mtd/nand.h +7 -0

index abda5c3..0cdb3b9 100644
@@ -634,6 +634,7 @@ struct nand_buffers {
  * @ecc_step_ds:	[INTERN] ECC step required by the @ecc_strength_ds,
  *                      also from the datasheet. It is the recommended ECC step
  *			size, if known; if unknown, set to zero.
+ * @onfi_timing_mode_ds:[INTERN] ONFI timing mode deduced from datasheet.
  * @numchips:		[INTERN] number of physical chips
  * @chipsize:		[INTERN] the size of one chip for multichip arrays
  * @pagemask:		[INTERN] page number mask = number of (pages / chip) - 1

@@ -718,6 +719,7 @@ struct nand_chip {
 	uint8_t bits_per_cell;
 	uint16_t ecc_strength_ds;
 	uint16_t ecc_step_ds;
+	int onfi_timing_mode_ds;
 	int badblockpos;
 	int badblockbits;
 

@@ -822,6 +824,10 @@ struct nand_chip {
  *               @ecc_step_ds in nand_chip{}, also from the datasheet.
  *               For example, the "4bit ECC for each 512Byte" can be set with
  *               NAND_ECC_INFO(4, 512).
+ * @onfi_timing_mode_ds: the ONFI timing mode supported by this NAND chip. This
+ *                       should be deduced from timings described in the
+ *                       datasheet.
+ *
  */
 struct nand_flash_dev {
 	char *name;

@@ -842,6 +848,7 @@ struct nand_flash_dev {
 		uint16_t strength_ds;
 		uint16_t step_ds;
 	} ecc;
+	int onfi_timing_mode_ds;
 };
 
 /**

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/nand_base.c | 154 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h     |  21 ++++++
 2 files changed, 175 insertions(+)

drivers/mtd/nand/nand_base.c +154 -0

index dbeb092..1c514a0 100644
@@ -1185,6 +1185,138 @@ EXPORT_SYMBOL(nand_lock);
 #endif
 
 /**
+ * nand_page_is_empty - check wether a NAND page contains only FFs
+ * @mtd:	mtd info
+ * @data:	data buffer
+ * @oob:	oob buffer
+ *
+ * Reads the data stored in the databuf buffer and check if it contains only
+ * FFs.
+ *
+ * Return true if it does else return false.
+ */
+bool nand_page_is_empty(struct mtd_info *mtd, void *data, void *oob)
+{
+	u8 *buf;
+	int length;
+	u32 pattern = 0xffffffff;
+	int bitflips = 0;
+	int cnt;
+
+	buf = data;
+	length = mtd->writesize;
+	while (length) {
+		cnt = length < sizeof(pattern) ? length : sizeof(pattern);
+		if (memcmp(&pattern, buf, cnt)) {
+			int i;
+			for (i = 0; i < cnt * 8; i++) {
+				if (!(buf[i / 8] &
+				      (1 << (i % 8)))) {
+					bitflips++;
+					if (bitflips > mtd->ecc_strength)
+						return false;
+				}
+			}
+		}
+
+		buf += sizeof(pattern);
+		length -= sizeof(pattern);
+	}
+
+	buf = oob;
+	length = mtd->oobsize;
+	while (length) {
+		cnt = length < sizeof(pattern) ? length : sizeof(pattern);
+		if (memcmp(&pattern, buf, cnt)) {
+			int i;
+			for (i = 0; i < cnt * 8; i++) {
+				if (!(buf[i / 8] &
+				      (1 << (i % 8)))) {
+					bitflips++;
+					if (bitflips > mtd->ecc_strength)
+						return false;
+				}
+			}
+		}
+
+		buf += sizeof(pattern);
+		length -= sizeof(pattern);
+	}
+
+	return true;
+}
+EXPORT_SYMBOL(nand_page_is_empty);
+
+/**
+ * nand_page_get_status - retrieve page status from the page status table (pst)
+ * @mtd:	mtd info
+ * @page:	page you want to get status on
+ *
+ * Return the page status.
+ */
+int nand_page_get_status(struct mtd_info *mtd, int page)
+{
+	struct nand_chip *chip = mtd->priv;
+	u8 shift = (page % 4) * 2;
+	uint64_t offset = page / 4;
+	int ret = NAND_PAGE_STATUS_UNKNOWN;
+
+	if (chip->pst)
+		ret = (chip->pst[offset] >> shift) & 0x3;
+
+	return ret;
+}
+EXPORT_SYMBOL(nand_page_get_status);
+
+/**
+ * nand_page_set_status - assign page status from in the page status table
+ * @mtd:	mtd info
+ * @page:	page you want to get status on
+ * @status:	new status to assign
+ */
+void nand_page_set_status(struct mtd_info *mtd, int page,
+			  enum nand_page_status status)
+{
+	struct nand_chip *chip = mtd->priv;
+	u8 shift;
+	uint64_t offset;
+
+	if (!chip->pst)
+		return;
+
+	shift = (page % 4) * 2;
+	offset = page / 4;
+	chip->pst[offset] &= ~(0x3 << shift);
+	chip->pst[offset] |= (status & 0x3) << shift;
+}
+EXPORT_SYMBOL(nand_page_set_status);
+
+/**
+ * nand_pst_create - create a page status table
+ * @mtd:	mtd info
+ *
+ * Allocate a page status table and assign it to the mtd device.
+ *
+ * Returns 0 in case of success or -ERRNO in case of error.
+ */
+int nand_pst_create(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+
+	if (chip->pst)
+		return 0;
+
+	chip->pst = kzalloc(mtd->size >>
+			    (chip->page_shift + mtd->subpage_sft + 2),
+			    GFP_KERNEL);
+	if (!chip->pst)
+		return -ENOMEM;
+
+	return 0;
+}
+EXPORT_SYMBOL(nand_pst_create);
+
+/**
  * nand_read_page_raw - [INTERN] read raw page data without ecc
  * @mtd: mtd info structure
  * @chip: nand chip info structure

@@ -2521,6 +2653,7 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
 		int bytes = mtd->writesize;
 		int cached = writelen > bytes && page != blockmask;
 		uint8_t *wbuf = buf;
+		int subpage;
 
 		WATCHDOG_RESET();
 		/* Partial page write? */

@@ -2547,6 +2680,14 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
 		if (ret)
 			break;
 
+		for (subpage = column / chip->subpagesize;
+		     subpage < (column + writelen) / chip->subpagesize;
+		     subpage++)
+			nand_page_set_status(mtd,
+					     (page << mtd->subpage_sft) +
+					     subpage,
+					     NAND_PAGE_FILLED);
+
 		writelen -= bytes;
 		if (!writelen)
 			break;

@@ -2804,6 +2945,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
 	int page, status, pages_per_block, ret, chipnr;
 	struct nand_chip *chip = mtd->priv;
 	loff_t len;
+	int i;
 
 	pr_debug("%s: start = 0x%012llx, len = %llu\n",
 			__func__, (unsigned long long)instr->addr,

@@ -2880,6 +3022,18 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
 			goto erase_exit;
 		}
 
+		for (i = 0; i < pages_per_block; i++) {
+			int subpage;
+			for (subpage = 0;
+			     subpage < 1 << mtd->subpage_sft;
+			     subpage++) {
+				nand_page_set_status(mtd,
+					((page + i) << mtd->subpage_sft) +
+					subpage,
+					NAND_PAGE_EMPTY);
+			}
+		}
+
 		/* Increment page address and decrement length */
 		len -= (1ULL << chip->phys_erase_shift);
 		page += pages_per_block;

include/linux/mtd/nand.h +21 -0

index 0cdb3b9..ef6a783 100644
@@ -547,6 +547,24 @@ struct nand_ecc_ctrl {
 			int page);
 };
 
+/*
+ * Constants for page status
+ */
+enum nand_page_status {
+	NAND_PAGE_STATUS_UNKNOWN,
+	NAND_PAGE_EMPTY,
+	NAND_PAGE_FILLED,
+};
+
+bool nand_page_is_empty(struct mtd_info *mtd, void *data, void *oob);
+
+int nand_page_get_status(struct mtd_info *mtd, int page);
+
+void nand_page_set_status(struct mtd_info *mtd, int page,
+			  enum nand_page_status status);
+
+int nand_pst_create(struct mtd_info *mtd);
+
 /**
  * struct nand_buffers - buffer structure for read/write
  * @ecccalc:	buffer pointer for calculated ECC, size is oobsize.

@@ -660,6 +678,7 @@ struct nand_buffers {
  * @bbt_md:		[REPLACEABLE] bad block table mirror descriptor
  * @badblock_pattern:	[REPLACEABLE] bad block scan pattern used for initial
  *			bad block scan.
+ * @pst:		[INTERN] page status table
  * @controller:		[REPLACEABLE] a pointer to a hardware controller
  *			structure which is shared among multiple independent
  *			devices.

@@ -750,6 +769,8 @@ struct nand_chip {
 
 	struct nand_bbt_descr *badblock_pattern;
 
+	uint8_t *pst;
+
 	void *priv;
 };
 

From: yassin <[email protected]>

Signed-off-by Roy Spliet <[email protected]>

---
 drivers/mtd/nand/nand_base.c | 101 ++++++++++++++++++++++++++-----------------
 1 file changed, 61 insertions(+), 40 deletions(-)

drivers/mtd/nand/nand_base.c +61 -40

index 1c514a0..83586cc 100644
@@ -4114,47 +4114,15 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
 }
 EXPORT_SYMBOL(nand_scan_ident);
 
-
-/**
- * nand_scan_tail - [NAND Interface] Scan for the NAND device
- * @mtd: MTD device structure
- *
- * This is the second phase of the normal nand_scan() function. It fills out
- * all the uninitialized function pointers with the defaults and scans for a
- * bad block table if appropriate.
+/*
+ * Initialize ECC struct:
+ *  - fill ECC struct with default function/values when these ones are undefined
+ *  - fill ECC infos based on MTD device
  */
-int nand_scan_tail(struct mtd_info *mtd)
+static int nand_ecc_ctrl_init(struct mtd_info *mtd, struct nand_ecc_ctrl *ecc)
 {
 	int i;
-	struct nand_chip *chip = mtd->priv;
-	struct nand_ecc_ctrl *ecc = &chip->ecc;
-	struct nand_buffers *nbuf;
 
-	/* New bad blocks should be marked in OOB, flash-based BBT, or both */
-	BUG_ON((chip->bbt_options & NAND_BBT_NO_OOB_BBM) &&
-			!(chip->bbt_options & NAND_BBT_USE_FLASH));
-
-	if (!(chip->options & NAND_OWN_BUFFERS)) {
-#ifndef __UBOOT__
-		nbuf = kzalloc(sizeof(*nbuf) + mtd->writesize
-				+ mtd->oobsize * 3, GFP_KERNEL);
-		if (!nbuf)
-			return -ENOMEM;
-		nbuf->ecccalc = (uint8_t *)(nbuf + 1);
-		nbuf->ecccode = nbuf->ecccalc + mtd->oobsize;
-		nbuf->databuf = nbuf->ecccode + mtd->oobsize;
-#else
-		nbuf = kzalloc(sizeof(struct nand_buffers), GFP_KERNEL);
-#endif
-
-		chip->buffers = nbuf;
-	} else {
-		if (!chip->buffers)
-			return -ENOMEM;
-	}
-
-	/* Set the internal oob buffer location, just after the page data */
-	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
 
 	/*
 	 * If no default placement scheme is given, select an appropriate one.

@@ -4180,9 +4148,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 		}
 	}
 
-	if (!chip->write_page)
-		chip->write_page = nand_write_page;
-
 	/*
 	 * Check ECC mode, default to software if 3byte/512byte hardware ECC is
 	 * selected and we have 256 byte pagesize fallback to software ECC

@@ -4349,6 +4314,62 @@ int nand_scan_tail(struct mtd_info *mtd)
 	}
 	ecc->total = ecc->steps * ecc->bytes;
 
+	return 0;
+}
+
+/**
+ * nand_scan_tail - [NAND Interface] Scan for the NAND device
+ * @mtd: MTD device structure
+ *
+ * This is the second phase of the normal nand_scan() function. It fills out
+ * all the uninitialized function pointers with the defaults and scans for a
+ * bad block table if appropriate.
+ */
+int nand_scan_tail(struct mtd_info *mtd)
+{
+	int ret;
+	struct nand_chip *chip = mtd->priv;
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+	struct nand_buffers *nbuf;
+
+	/* New bad blocks should be marked in OOB, flash-based BBT, or both */
+	BUG_ON((chip->bbt_options & NAND_BBT_NO_OOB_BBM) &&
+			!(chip->bbt_options & NAND_BBT_USE_FLASH));
+
+	if (!(chip->options & NAND_OWN_BUFFERS)) {
+#ifndef __UBOOT__
+		nbuf = kzalloc(sizeof(*nbuf) + mtd->writesize
+				+ mtd->oobsize * 3, GFP_KERNEL);
+		if (!nbuf)
+			return -ENOMEM;
+		nbuf->ecccalc = (uint8_t *)(nbuf + 1);
+		nbuf->ecccode = nbuf->ecccalc + mtd->oobsize;
+		nbuf->databuf = nbuf->ecccode + mtd->oobsize;
+#else
+		nbuf = kzalloc(sizeof(struct nand_buffers), GFP_KERNEL);
+#endif
+
+		chip->buffers = nbuf;
+	} else {
+		if (!chip->buffers)
+			return -ENOMEM;
+	}
+
+	/* Set the internal oob buffer location, just after the page data */
+	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
+
+	if (!chip->write_page)
+		chip->write_page = nand_write_page;
+
+	/* Initialize ECC struct */
+	ret = nand_ecc_ctrl_init(mtd, ecc);
+	if (ret) {
+		if (!(chip->options & NAND_OWN_BUFFERS))
+			kfree(chip->buffers);
+
+		return ret;
+	}
+
 	/* Allow subpage writes up to ecc.steps. Not possible for MLC flash */
 	if (!(chip->options & NAND_NO_SUBPAGE_WRITE) && nand_is_slc(chip)) {
 		switch (ecc->steps) {

Based on BBrezillons work, minus per-partition support. Changes to support that would be quite invasive while it hasn't been solved yet for Linux.

Heavily based on BBrezillon's (downstream) driver. Most noticable differences
- No per-partition ECC settings. Partitions in U-boot are quite different from Linux
- U-boot register definitions, shared with sunxi_nand_spl
- FDT parsing in-line, there's no framework method yet

Quoted 7 lines · On Fri, 5 Jun 2015 13:52:40 +0200 Roy Spliet <[email protected]> wrote:

Heavily based on BBrezillon's (downstream) driver. Most noticable differences
- No per-partition ECC settings. Partitions in U-boot are quite different from Linux
- U-boot register definitions, shared with sunxi_nand_spl
- FDT parsing in-line, there's no framework method yet

I'll try to review this driver next week.

Signed-off-by Roy Spliet <[email protected]>

---
 arch/arm/dts/sun7i-a20-olinuxino-lime.dts | 41 ++++++++++++++
 arch/arm/dts/sun7i-a20.dtsi               | 90 +++++++++++++++++++++++++++++++
 2 files changed, 131 insertions(+)

arch/arm/dts/sun7i-a20-olinuxino-lime.dts +23 -0

index 6592cb2..cc5e65d 100644
@@ -181,3 +181,44 @@
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
 };
+
+&nfc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>;
+	status = "okay";
+
+	nand at 0 {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		reg = <0>;
+		allwinner,rb = <0>;
+		nand-ecc-mode = "hw";
+		nand-ecc-strength = <40>;
+		nand-ecc-step-size = <1024>;
+		nand-rnd-mode = "hw";
+		nand-randomizer-seeds = /bits/ 16 <
+			0x2b75 0x0bd0 0x5ca3 0x62d1 0x1c93 0x07e9 0x2162 0x3a72
+			0x0d67 0x67f9 0x1be7 0x077d 0x032f 0x0dac 0x2716 0x2436
+			0x7922 0x1510 0x3860 0x5287 0x480f 0x4252 0x1789 0x5a2d
+			0x2a49 0x5e10 0x437f 0x4b4e 0x2f45 0x216e 0x5cb7 0x7130
+			0x2a3f 0x60e4 0x4dc9 0x0ef0 0x0f52 0x1bb9 0x6211 0x7a56
+			0x226d 0x4ea7 0x6f36 0x3692 0x38bf 0x0c62 0x05eb 0x4c55
+			0x60f4 0x728c 0x3b6f 0x2037 0x7f69 0x0936 0x651a 0x4ceb

Signed-off-by Roy Spliet <[email protected]>

---
  board/sunxi/Kconfig            |  8 +++-----
  drivers/mtd/Makefile           |  1 +
  include/configs/sunxi-common.h | 33 +++++++++++++++++++++++++--------
  3 files changed, 29 insertions(+), 13 deletions(-)

board/sunxi/Kconfig +3 -5

index cf58d73..37bbd0f 100644
@@ -269,17 +269,15 @@ config MMC_SUNXI_SLOT_EXTRA
  	slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
  	support for this.
 
-config SPL_NAND_SUPPORT
-	bool "SPL/NAND mode support"
+config NAND_SUNXI
+	bool "NAND support"
  	depends on SPL
  	default n
  	---help---
  	  This enables support for booting from NAND internal
  	  memory. U-Boot SPL doesn't detect where is it load from,
  	  therefore this option is needed to properly load image from
-	  flash. Option also disables MMC functionality on U-Boot due to
-	  initialization errors encountered, when both controllers are
-	  enabled.
+	  flash.
 
  config USB0_VBUS_PIN
  	string "Vbus enable pin for usb0 (otg)"

drivers/mtd/Makefile +1 -0

index 5467a95..124b0f9 100644
@@ -18,3 +18,4 @@ obj-$(CONFIG_FTSMC020) += ftsmc020.o
  obj-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o
  obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o
  obj-$(CONFIG_ST_SMI) += st_smi.o
+obj-$(CONFIG_MTD_UBI) += ubi/

include/configs/sunxi-common.h +0 -0

index cce0441..ec28c40 100644

include/configs/sunxi-common.h +24 -7

@@ -326,10 +326,31 @@ extern int soft_i2c_gpio_scl;
  #define CONFIG_ENV_IS_NOWHERE
  #endif
 
-#ifdef CONFIG_SPL_NAND_SUPPORT
+#ifdef CONFIG_NAND_SUNXI
+#ifndef CONFIG_NAND_SUNXI_GPC_PORTS
+#error "No NAND GPC ports defined, NAND unsupported"
+#endif /* CONFIG_NAND_SUNXI_GPC_PORTS */
  #define CONFIG_NAND
  #define CONFIG_SYS_NAND_SELF_INIT
-#define CONFIG_NAND_SUNXI
+#define CONFIG_SYS_MAX_NAND_DEVICE 8
+
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+
+/* Requirements for UBI */
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_MTD_DEVICE
+
+#define CONFIG_SPL_NAND_SUPPORT
+
+#define CONFIG_MTD_PARTITIONS
+/*
+#define CONFIG_MTD_DEBUG
+#define CONFIG_MTD_DEBUG_VERBOSE		MTD_DEBUG_LEVEL3
+*/
  #define CONFIG_CMD_SPL_WRITE_SIZE		0x000400
  #define CONFIG_SYS_NAND_U_BOOT_OFFS		0x008000
 

@@ -338,11 +359,7 @@ extern int soft_i2c_gpio_scl;
  #define CONFIG_NAND_SUNXI_ECC_STEP		1024
  #define CONFIG_NAND_SUNXI_ECC_STRENGTH		40
  #define CONFIG_NAND_SUNXI_ADDR_CYCLES		5
-
-#ifndef CONFIG_NAND_SUNXI_GPC_PORTS
-#error "No NAND GPC ports defined, NAND unsupported"
-#endif
-#endif /* CONFIG_SPL_NAND_SUPPORT */
+#endif /* CONFIG_NAND_SUNXI */
 
  #define CONFIG_MISC_INIT_R
  #define CONFIG_SYS_CONSOLE_IS_IN_ENV

include/configs/sunxi-common.h line 119

Quoted 9 lines

include/configs/sunxi-common.h +1 -1

@@ -113,7 +113,7 @@
  #endif
 
  /* 4MB of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (4 << 20))
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (64 << 20))
 
  /*
   * Miscellaneous configurable options

Please update the comment about malloc_pool size to match :)

Quoted 10 lines

include/configs/sunxi-common.h line 119

Quoted 9 lines

include/configs/sunxi-common.h +1 -1

@@ -113,7 +113,7 @@
   #endif
 
   /* 4MB of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (4 << 20))
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (64 << 20))
 
   /*
    * Miscellaneous configurable options

Please update the comment about malloc_pool size to match :)

...and explain in the commit log why this needs increasing as part of this change.

Ian.

Oh yes, thanks for pointing this one out. I increased the malloc pool during debugging as google hinted towards UBI being rather memory-hungry, but forgot to double-check whether it was required. I just did, and as it turns out it really only needs to be increased to 8MiB for UBI to work in my set-up. As we have plenty of memory anyway, should I allocate some extra headroom for set-ups I haven't tested (e.g. many partitions, large bad-block tables etc.) and go for 16MiB instead?

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

Hello,

Quoted 29 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
  include/configs/sunxi-common.h | 9 +++++++++
  1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
  #define BOOT_TARGET_DEVICES_USB(func)
  #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
  #define BOOT_TARGET_DEVICES(func) \
         BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
         BOOT_TARGET_DEVICES_SCSI(func) \
         BOOT_TARGET_DEVICES_USB(func) \
         func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
         MEM_LAYOUT_ENV_SETTINGS \

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 5 lines

include/configs/sunxi-common.h +2 -0

         "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
         "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
         BOOTENV

From what I heard the nand boot partition size should be specified in
nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

While it is fine for testing to hand-edit the environment the final nand support should have

1) way to express the boot partition size in nand pages
2) way to make the main partition start at the end of boot partition and extend to the end of the flash

This should probably also go to Linux.

Thanks

Michal

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Hello,

On 5 June 2015 at 13:52, Roy Spliet <[email protected]> wrote:

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +9 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV
 

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Although I believe you have the facts mostly right, they do not apply in this situation.
What you are looking for is the partition definition for U-boot. At this point the boot
rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot

2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

Quoted 48 lines

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Hello,

On 5 June 2015 at 13:52, Roy Spliet <[email protected]> wrote:

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
  include/configs/sunxi-common.h | 9 +++++++++
  1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +9 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
  #define BOOT_TARGET_DEVICES_USB(func)
  #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
  #define BOOT_TARGET_DEVICES(func) \
         BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
         BOOT_TARGET_DEVICES_SCSI(func) \
         BOOT_TARGET_DEVICES_USB(func) \
         func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
         MEM_LAYOUT_ENV_SETTINGS \
         "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
         "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
         BOOTENV
 
 From what I heard the nand boot partition size should be specified in

nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 10 lines

Although I believe you have the facts mostly right, they do not apply in this situation.
What you are looking for is the partition definition for U-boot. At this point the boot
rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot

OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define.

Quoted 2 lines

2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between.

If support for non-uniform flash format is not available then there are basically two options:

1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition

2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL.

The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.]

Thanks

Michal

Dear Michal,

Op 08-06-15 om 10:54 schreef Michal Suchanek:

Quoted 81 lines · Roy Spliet

Quoted 48 lines

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Hello,

On 5 June 2015 at 13:52, Roy Spliet <[email protected]> wrote:

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +9 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV
 

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 10 lines

Although I believe you have the facts mostly right, they do not apply in this situation.
What you are looking for is the partition definition for U-boot. At this point the boot
rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot

OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define.

Quoted 2 lines

2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between.

If support for non-uniform flash format is not available then there are basically two options:

1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition

2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL.

Quoted 5 lines

The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.]

The solution already implemented now and carried to Hans' tree is 1) with the size of SPL aligned to 8KB blocks (the largest of the page sizes attempted). The modes tried by BROM are listed in [1]. SPL currently tries only a single mode whose params are defined in sunxi-common.h, but this is likely to change to a "brute-force" approach to resemble BROM in the near future.
Yours,

Roy

Quoted 4 lines

Thanks

Michal

[1] https://linux-sunxi.org/NAND

Signature · 10 lines

IMAGINE IT >> MAKE IT

Meet us online at Twitter <http://twitter.com/ultimaker>, Facebook <http://facebook.com/ultimaker>, Google+ <http://google.com/+Ultimaker>

www.ultimaker.com

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Roy
Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls.

Quoted 120 lines · Roy Spliet

Dear Michal,

Op 08-06-15 om 10:54 schreef Michal Suchanek:

Quoted 81 lines · Roy Spliet

Quoted 48 lines

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Hello,

On 5 June 2015 at 13:52, Roy Spliet <[email protected]> wrote:

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
  include/configs/sunxi-common.h | 9 +++++++++
  1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +9 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
  #define BOOT_TARGET_DEVICES_USB(func)
  #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
  #define BOOT_TARGET_DEVICES(func) \
         BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
         BOOT_TARGET_DEVICES_SCSI(func) \
         BOOT_TARGET_DEVICES_USB(func) \
         func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
         MEM_LAYOUT_ENV_SETTINGS \
         "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
         "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
         BOOTENV
 
 From what I heard the nand boot partition size should be specified in

nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 10 lines

Although I believe you have the facts mostly right, they do not apply in this situation.
What you are looking for is the partition definition for U-boot. At this point the boot
rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot

OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define.

Quoted 2 lines

2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between.

If support for non-uniform flash format is not available then there are basically two options:

1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition

2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL.

Quoted 5 lines

The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.]

The solution already implemented now and carried to Hans' tree is 1) with the size of SPL aligned to 8KB blocks (the largest of the page sizes attempted). The modes tried by BROM are listed in [1]. SPL currently tries only a single mode whose params are defined in sunxi-common.h, but this is likely to change to a "brute-force" approach to resemble BROM in the near future.
Yours,

Roy

Quoted 3 lines

Thanks

Michal

[1] https://linux-sunxi.org/NAND

Signature · 10 lines

IMAGINE IT >> MAKE IT

Meet us online at Twitter <http://twitter.com/ultimaker>, Facebook <http://facebook.com/ultimaker>, Google+ <http://google.com/+Ultimaker>

www.ultimaker.com

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hello Yassin,

Op 08-06-15 om 12:48 schreef Yassin:

Quoted 2 lines

Hi Roy
Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls.

Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing:
load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need "for free". I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run.

Roy, Yassin,

Quoted 5 lines · On Mon, 08 Jun 2015 13:35:04 +0200 Roy Spliet <[email protected]> wrote:

Hello Yassin,

Op 08-06-15 om 12:48 schreef Yassin:

Quoted 2 lines

Hi Roy
Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls.

Quoted 11 lines

Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing:
load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need "for free". I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run.

Actually, the more I think about the more I agree with Yassin's suggestion. We currently don't have any standard way to attach a specific setting to a partition (even in Linux, and I hope I'll be able to work on this aspect soon).
So for now, I really think we should reuse the existing/standard way of declaring partitions in u-boot (mtdparts + mtdids variables + the mtdparts command) and a sunxi specific commands to configure the ECC and Randomizer config.
Once we have settled on something in Linux, we will be able to port it to u-boot and get rid of these sunxi specific command, but in the meantime this will allow us to boot a linux kernel (and even flash an SPL) from u-boot without introducing heavy changes in the u-boot MTD layer.

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Quoted 32 lines

Hello,

Quoted 29 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
  include/configs/sunxi-common.h | 9 +++++++++
  1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
  #define BOOT_TARGET_DEVICES_USB(func)
  #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
  #define BOOT_TARGET_DEVICES(func) \
         BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
         BOOT_TARGET_DEVICES_SCSI(func) \
         BOOT_TARGET_DEVICES_USB(func) \
         func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
         MEM_LAYOUT_ENV_SETTINGS \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 5 lines

include/configs/sunxi-common.h +2 -0

         "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
         "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
         BOOTENV

From what I heard the nand boot partition size should be specified in
nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows:
0-2MB U-Boot-SPL + U-Boot
2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

The mtdparts env variable defines only the main file system because that's the only place with relevant files for U-Boot.
This said: I have replaced the default file system with a "custom" UBI FS containing just a boot and a rootfs partition. I am unsure whether these defaults apply for the Android image that ships with the Olimex boards. But then again: that image also ships with a boot-loader, so do we care?

Quoted 11 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

While it is fine for testing to hand-edit the environment the final nand support should have

1) way to express the boot partition size in nand pages
2) way to make the main partition start at the end of boot partition and extend to the end of the flash

Quoted 1 line

This should probably also go to Linux.

Linux can define partitions in the device tree. I'd prefer to carry this approach to U-boot, but current U-Boot has the partitioning part of the MTD code hacked away and replaced by custom mtdparts code without OF support. Doing this proper requires getting rid of the latter, which will likely break a lot of legacy. So as far as I agree, I have to warn that is a longer-term project, extended further by the ongoing (justified) discussion we are having regarding the MTD partitioning code in upstream Linux that may or may not lead to parts of the framework being re-architected.

Roy

Quoted 3 lines

Thanks

Michal

Hi Roy,

Quoted 80 lines · Roy Spliet

Hello Michal,

Op 07-06-15 om 18:48 schreef Michal Suchanek:

Quoted 34 lines

Hello,

Quoted 31 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
  include/configs/sunxi-common.h | 9 +++++++++
  1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
  #define BOOT_TARGET_DEVICES_USB(func)
  #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
  #define BOOT_TARGET_DEVICES(func) \
         BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
         BOOT_TARGET_DEVICES_SCSI(func) \
         BOOT_TARGET_DEVICES_USB(func) \
         func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
         MEM_LAYOUT_ENV_SETTINGS \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 5 lines

include/configs/sunxi-common.h +2 -0

         "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
         "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+ "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
         BOOTENV

From what I heard the nand boot partition size should be specified in
nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Although I believe you have the facts mostly right, they do not apply in this situation.
What you are looking for is the partition definition for U-boot. At this point the boot
rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex
+ Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot
2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system

The mtdparts env variable defines only the main file system because that's the only
place with relevant files for U-Boot.
This said: I have replaced the default file system with a "custom" UBI FS containing
just a boot and a rootfs partition. I am unsure whether these defaults apply for the
Android image that ships with the Olimex boards. But then again: that image also
ships with a boot-loader, so do we care?

Quoted 4 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

Quoted 8 lines

While it is fine for testing to hand-edit the environment the final nand support should have

1) way to express the boot partition size in nand pages
2) way to make the main partition start at the end of boot partition and extend to the end of the flash

This should probably also go to Linux.

Quoted 13 lines

Linux can define partitions in the device tree. I'd prefer to carry this approach to U-boot,
but current U-Boot has the partitioning part of the MTD code hacked away and replaced by
custom mtdparts code without OF support. Doing this proper requires getting rid of the
latter, which will likely break a lot of legacy. So as far as I agree, I have to warn that is
a longer-term project, extended further by the ongoing (justified) discussion we are having
regarding the MTD partitioning code in upstream Linux that may or may not lead to parts
of the framework being re-architected.

Last time I discussed this with some kernel people, they pointed me to the fact that
the kernel actually parses partition info provided by u-boot through the u-boot mtdparts
command, and that that is the preferred way to pass partition info to the kernel, so rather
then adding dts partition info to u-boot we would need to teach the existing kernel mtdpart
code to deal with separate ecc / random setting and maybe use a list of hardcoded
partitition names for which to use the brom compatible settings. These are all things
which we need to figure out on the kernel side, it would be good to get a discussion
started on this with the kernel mtd people.

Note that we will also need to have a u-boot env partition somewhare either at the
nandpart level, or as a ubi volume, assuming the u-boot env code can deal with
ubi volumes (we are in the full u-boot environment when reading the env.)

Regards,

Hans

Quoted 7 lines

Roy

Quoted 3 lines

Thanks

Michal

Hello,

Quoted 30 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 4 lines

include/configs/sunxi-common.h +2 -0

        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

While it is fine for testing to hand-edit the environment the final nand support should have

1) way to express the boot partition size in nand pages

2) way to make the main partition start at the end of boot partition and extend to the end of the flash

Hi Michal,

Quoted 33 lines · On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek <[email protected]> wrote:

Hello,

Quoted 30 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 4 lines

include/configs/sunxi-common.h +2 -0

        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages.
The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one.

Quoted 5 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block.

Quoted 1 line

Quoted 4 lines

While it is fine for testing to hand-edit the environment the final nand support should have

1) way to express the boot partition size in nand pages

Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes).

Quoted 3 lines

2) way to make the main partition start at the end of boot partition and extend to the end of the flash

Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation).

Quoted 47 lines · Boris Brezillon

Hi Michal,

Quoted 33 lines · On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek <[email protected]> wrote:

Hello,

Quoted 30 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 4 lines

include/configs/sunxi-common.h +2 -0

        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 7 lines

AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages.
The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one.

However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway.

Quoted 13 lines

Quoted 5 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block.

Quoted 4 lines

While it is fine for testing to hand-edit the environment the final nand support should have

Quoted 5 lines

Quoted 1 line

1) way to express the boot partition size in nand pages

Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes).

Because the block size is not the same on all flash chips, obviously.

If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it.

Quoted 7 lines

Quoted 4 lines

2) way to make the main partition start at the end of boot partition and extend to the end of the flash

Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation).

Since these are block aligned anyway there should be no problem.

And if you can express the size in blocks you can just make the main partition start the next block after boot0. What is missing is the ability to extend to the end of medium to be feature compatible with Chinese software that uses this to flash same firmware to tablets with different nand size. I think this is generally desirable anyway.

Quoted 57 lines · On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek <[email protected]> wrote:

Quoted 47 lines · Boris Brezillon

Hi Michal,

Quoted 33 lines · On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek <[email protected]> wrote:

Hello,

Quoted 30 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 4 lines

include/configs/sunxi-common.h +2 -0

        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 7 lines

AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages.
The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one.

Quoted 4 lines

However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway.

Hm, I don't get your point.
You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach).

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block.

Quoted 4 lines

While it is fine for testing to hand-edit the environment the final nand support should have

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

1) way to express the boot partition size in nand pages

Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes).

Because the block size is not the same on all flash chips, obviously.

And that's why partitions are defined in the board dts, and not the SoC dtsi...

Quoted 1 line

Quoted 2 lines

If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it.

I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific.
What's the problem with having different partition layout depending on the board ?

Quoted 65 lines · Boris Brezillon

Quoted 61 lines · On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek <[email protected]> wrote:

Quoted 47 lines · Boris Brezillon

Hi Michal,

Quoted 33 lines · On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek <[email protected]> wrote:

Hello,

Quoted 30 lines · Roy Spliet

Based on the default layout of the android image used at least on Olimex Lime

Signed-off-by Roy Spliet <[email protected]>

---
 include/configs/sunxi-common.h | 9 +++++++++
 1 file changed, 9 insertions(+)

include/configs/sunxi-common.h +7 -0

index ec28c40..b38f2f5 100644
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
        BOOT_TARGET_DEVICES_MMC(func) \
+       BOOT_TARGET_DEVICES_NAND(func) \
        BOOT_TARGET_DEVICES_SCSI(func) \
        BOOT_TARGET_DEVICES_USB(func) \
        func(PXE, pxe, na) \

@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
        MEM_LAYOUT_ENV_SETTINGS \
        "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \

Quoted 8 lines

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 453

Quoted 4 lines

include/configs/sunxi-common.h +2 -0

        "console=ttyS0,115200\0" \
+       "mtdids=nand0=mtd2\0" \
+       "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
        BOOTENV

From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size.

Quoted 7 lines

AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages.
The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one.

However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway.

Quoted 4 lines

Hm, I don't get your point.
You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach).

and how do you tell the kernel that these partitions follow the boot0 taking up one block when you only count in bytes?

Quoted 29 lines

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines

I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver.

AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block.

Quoted 4 lines

While it is fine for testing to hand-edit the environment the final nand support should have

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

1) way to express the boot partition size in nand pages

Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes).

Because the block size is not the same on all flash chips, obviously.

And that's why partitions are defined in the board dts, and not the SoC dtsi...

Quoted 3 lines

If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it.

Quoted 5 lines

I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific.
What's the problem with having different partition layout depending on the board ?

Why do we have nand chip detection then?

We can just write the chip parameters in DT and have everything in one place at least.

If we cannot use the detected parameters to infer the related values in DT then the detection is useless for DT based archs.

Following up on earlier SPL patches, here a series based on Yassin Jaffer's work to bring NAND support to U-boot. RFC because I know that the sunxi nand configuration options are dependent on a work-in-progress by Daniel - trying to deliver a single SPL for both MMC and NAND boot.

Given I have spent the past few weeks learning how Boris' original driver works, I have probably grown a bit blind for potentially existing issues. Please provide plenty of feedback so I can bring this in good shape.

Patches tested on an Olimex Lime with 4GB Hynix nand. Has a partition as defined in sunxi-common.h with two UBIFS partitions (boot, rootfs) set up in Linux. To me it feels self-explanatory how to set this up, but I've spent the last few weeks full-time on this, implying my view of the world and how it revolves around MTD is rather distorted. Feel free to ask directed questions if you desire assistance in setting up and/or testing.

Following up on earlier SPL patches, here a series based on Yassin Jaffer's work to bring NAND support to U-boot. RFC because I know that the sunxi nand configuration options are dependent on a work-in-progress by Daniel - trying to deliver a single SPL for both MMC and NAND boot.
Given I have spent the past few weeks learning how Boris' original driver works, I have probably grown a bit blind for potentially existing issues. Please provide plenty of feedback so I can bring this in good shape.

Patches tested on an Olimex Lime with 4GB Hynix nand. Has a partition as defined in sunxi-common.h with two UBIFS partitions (boot, rootfs) set up in Linux. To me it feels self-explanatory how to set this up, but I've spent the last few weeks full-time on this, implying my view of the world and how it revolves around MTD is rather distorted. Feel free to ask directed questions if youdesire assistance in setting up and/or testing.

Following up on earlier SPL patches, here a series based on Yassin Jaffer's work to bring NAND support to U-boot. RFC because I know that the sunxi nand configuration options are dependent on a work-in-progress by Daniel - trying to deliver a single SPL for both MMC and NAND boot.
Given I have spent the past few weeks learning how Boris' original driver works, I have probably grown a bit blind for potentially existing issues. Please provide plenty of feedback so I can bring this in good shape.

Patches tested on an Olimex Lime with 4GB Hynix nand. Has a partition as defined in sunxi-common.h with two UBIFS partitions (boot, rootfs) set up in Linux. To me it feels self-explanatory how to set this up, but I've spent the last few weeks full-time on this, implying my view of the world and how it revolves around MTD is rather distorted. Feel free to ask directed questions if you desire assistance in setting up and/or testing.
Thanks!