mtd: part: Add BCM962368 CFE partitioning support

Add partitioning support for BCM963268 boards with CFE bootloaders. The following partitions are defined:

  "boot":           CFE and nvram data
  "rootfs":         Currently selected rootfs
  "data":           Configuration data

"rootfs1_update": Container for the whole flash area used
for the first rootfs to allow it to be updated.
"rootfs2_update": Container for the whole flash area used
for the second rootfs to allow it to be updated.
"rootfs_other": The other (not currently selected) rootfs

Example:

[    1.904302] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[    1.911000] nand: Macronix NAND 128MiB 3,3V 8-bit
[    1.915855] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    1.923797] bcm6368_nand 10000200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, Hamming ECC
[    1.936994] Bad block table found at page 65472, version 0x01
[    1.944121] Bad block table found at page 65408, version 0x01
[    1.951166] nand_read_bbt: bad block at 0x000007480000
[    1.990043] bcm963268part: rootfs1: CFE boot tag found at 0x20000 with version 6, board type 963168VX and sequence number 2
[    2.003060] bcm963268part: rootfs2: CFE boot tag found at 0x4000000 with version 6, board type 963168VX and sequence number 1
[    2.015159] bcm963268part: CFE bootline selected latest image rootfs1
[    2.022080] 6 bcm963268part partitions found on MTD device brcmnand.0
[    2.042659] Creating 6 MTD partitions on "brcmnand.0":
[    2.048025] 0x000000000000-0x000000020000 : "boot"
[    2.062134] 0x000000040000-0x000001120000 : "rootfs"
[    2.077632] 0x000007b00000-0x000007f00000 : "data"
[    2.091363] 0x000000020000-0x000003ac0000 : "rootfs1_update"
[    2.106228] 0x000004000000-0x000007ac0000 : "rootfs2_update"
[    2.121093] 0x000004020000-0x000005060000 : "rootfs_other"

The nvram contains the offset and size of the boot, rootfs1, rootfs2 and data partitions. The presence of CFE and nvram is verified by reading from the boot partition which is assumed to be at offset 0 and the process aborts if the nvram read indicates that this is not the case.

There is bcm_tag information at the start of each rootfs that is used to determine which rootfs is newer and what its real offset/size is.

The CFE bootline or nvram partition number is used to select a rootfs.

---
I'm aware that this is not compatible with the mtd partition/device tree reorganisation patches and will rework the patch when this is committed.

Should I try to put the "struct bcm963268_nvram" in a common header file for all 63xx SoCs? It's hard to know if there is only one purpose for each byte in the nvram across all SoCs or whether it would be a complex type involving unions for different SoCs.

The partitioning needs to match what exists already for this board so that it's practical to swap between an flash image released by the manufacturer/distributor of the hardware, and a custom image based on the latest vanilla kernel.

 drivers/mtd/Kconfig         |  21 +++
 drivers/mtd/Makefile        |   1 +
 drivers/mtd/bcm963268part.c | 373 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 395 insertions(+)
 create mode 100644 drivers/mtd/bcm963268part.c

index 42cc953..63cb2db 100644
@@ -148,6 +148,27 @@ config MTD_BCM63XX_PARTS
 	  This provides partions parsing for BCM63xx devices with CFE
 	  bootloaders.
 
+config MTD_BCM963268_PARTS
+	tristate "BCM963268 CFE partitioning support"
+	depends on BMIPS_GENERIC
+	select CRC32
+	help
+	  This provides partitions parsing for BCM963268 boards with CFE
+	  bootloaders. The following partitions are defined:
+	    "boot":           CFE and nvram data
+	    "rootfs":         Currently selected rootfs
+	    "data":           Configuration data
+	    "rootfs1_update": Container for the whole flash area used
+	                      for the first rootfs to allow it to be
+	                      updated.
+	    "rootfs2_update": Container for the whole flash area used
+	                      for the second rootfs to allow it to be
+	                      updated.
+	    "rootfs_other":   The other (not currently selected) rootfs
+
+	  A decision is made regarding which of the two rootfs is to be
+	  used based on the nvram data.
+
 config MTD_BCM47XX_PARTS
 	tristate "BCM47XX partitioning support"
 	depends on BCM47XX || ARCH_BCM_5301X

index 99bb9a1..f0f4140 100644
@@ -12,6 +12,7 @@ obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
 obj-$(CONFIG_MTD_AFS_PARTS)	+= afs.o
 obj-$(CONFIG_MTD_AR7_PARTS)	+= ar7part.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)	+= bcm63xxpart.o
+obj-$(CONFIG_MTD_BCM963268_PARTS) += bcm963268part.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)	+= bcm47xxpart.o
 
 # 'Users' - code which presents functionality to userspace.

2.1.4

-- 
Simon Arlott

Even harder is knowing what vendors ended up using in the reserved fields when they decided on a particular reference design and started to build their product...

I would look at what exists in the OpenWrt tree and create e.g:
include/uapi/linux/bcm963xx_nvram.h or something along these lines so we have at least a central location where the (potentially) different NVRAM formats for imagetag are there.

What motivated created a separate partition parser rather then using the extended the existing one?

I would imagine that, at some point, the partition parser could know what kind of flash it needs to parse: SPI/P-NOR or NAND, and based on that, do an appropriate definition?

Florian

I started off doing that but had to split it up because how it handles the nvram and bcm_tag to construct the partition layout is significantly different. The nvram isn't even read from flash in bcm63xxpart, and the psi size value isn't used by bcm963268.

With the device tree changes Brian's introducing it can be specified in there, otherwise a common parser would need to read from the miscStrapBus register which would be difficult for a partition parser as it's not a device and has no memory resources.

Simon Arlott