[OpenWrt-Devel] [PATCH 4/6] bcm53xx: bcm47xxpart: add support for parsing device tree partitions

Bjørn Mork bjorn at mork.no
Sat May 16 07:54:08 EDT 2015

Hauke Mehrtens <hauke at hauke-m.de> writes:

> On 05/16/2015 12:53 PM, Álvaro Fernández Rojas wrote:
>> Signed-off-by: Álvaro Fernández Rojas <noltari at gmail.com>
>> ---
>>  ...-bcm47xxpart-parse-device-tree-partitions.patch | 156 +++++++++++++++++++++
>>  1 file changed, 156 insertions(+)
>>  create mode 100644 target/linux/bcm53xx/patches-3.18/401-mtd-bcm47xxpart-parse-device-tree-partitions.patch
> What is the difference to just using the existing device tree  partition
> parser: drivers/mtd/ofpart.c ?

I wondered about the same...

Looking at the patch, it seems this solves an issue I am having with the
Linksys EA6700 (another bcm53xx) as well: We want some way to run the
TRX parser on the "firmware" partition(s), while describing the rest of
the layout in the device tree.  The probing strategy of the bcm47xxpart
fails with all the "devinfo" and "nvram" data spread all over, in
addition to the trailing vendor data partition ("asus" on the RT-AC87U
and "brcmnand" on the EA6700).  This could probably be fixed by careful
tuning of the parser.  But I believe that makes it unnecessary complex,
risking regressions on all the routers where the current parser works

Using a combination of device tree and a TRX parser looks like a much
better alternative.

Note that the Linksys routers have *two* TRX partitions due to the
Linksys dual-image failsafe implementation.  Ideally the parser should
take this into account when naming the "linux" and "rootfs" partitions.

Just to illustrate.  This is the EA6700 stock firmware partition layout: 

Creating 6 MTD partitions on "nflash":
0x000000000000-0x000000080000 : "boot"
0x000000080000-0x000000200000 : "nvram"
0x000000200000-0x000001f00000 : "linux"
0x0000003d3608-0x000001f00000 : "rootfs"
0x000001f00000-0x000003c00000 : "linux2"
0x00000213642c-0x000003c00000 : "rootfs2"
Creating 1 MTD partitions on "brcmnand":
0x000003c00000-0x000008000000 : "brcmnand"

This is the current bcm47xxpart parser result on the same router:

[    3.099341] 9 bcm47xxpart partitions found on MTD device bcm_nand
[    3.105408] Creating 9 MTD partitions on "bcm_nand":
[    3.110365] 0x000000000000-0x000000080000 : "boot"
[    3.116753] 0x000000080000-0x000000180000 : "nvram"
[    3.124461] 0x000000180000-0x000000200000 : "nvram"
[    3.131199] 0x000000200000-0x00000020001c : "firmware"
[    3.137390] 0x00000020001c-0x0000003d3608 : "linux"
[    3.159331] 0x0000003d3608-0x000001f00000 : "rootfs"
[    3.247077] 0x000000f40000-0x000001f00000 : "rootfs_data"
[    3.283079] 0x000001f00000-0x000008000000 : "firmware"
[    3.473070] 0x000001f0001c-0x00000213642c : "linux"
[    3.495495] 0x00000213642c-0x000008000000 : "rootfs"

Note that the stock firmware isn't entirely agreeing with the CFE
partition layout either.  In particular, it ignores the 512KB "devinfo"
partition starting at 180000 (which the bcm47xxpart parser more
correctly has identified as another "nvram" partition):

nflash0              AMD NAND flash size 131072KB
nflash0.boot         AMD NAND flash offset 00000000 size 512KB
nflash0.nvram        AMD NAND flash offset 00080000 size 1024KB
nflash0.devinfo      AMD NAND flash offset 00180000 size 512KB
nflash0.trx          AMD NAND flash offset 00200000 size 1KB
nflash0.os           AMD NAND flash offset 0020001C size 29696KB
nflash0.trx2         AMD NAND flash offset 01F00000 size 1KB
nflash0.os2          AMD NAND flash offset 01F0001C size 29696KB
nflash1.boot         AMD NAND flash offset 00000000 size 512KB
nflash1.nvram        AMD NAND flash offset 00080000 size 1024KB
nflash1.devinfo      AMD NAND flash offset 00180000 size 512KB
nflash1.trx          AMD NAND flash offset 00200000 size 29696KB
nflash1.trx2         AMD NAND flash offset 01F00000 size 29696KB
nflash1.brcmnand     AMD NAND flash offset 03C00000 size 69632KB

In any case, I believe this is best described in device tree.  We just
need some method to parse the internals of the TRX partitions.  

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list