Odd flash layout on Linksys E5600

I am working on porting Linksys E5600 router. When going through the boot log of the router I found following:

Creating 9 MTD partitions on "MT7621-NAND":
0x000000000000-0x000007f80000 : "ALL"
0x000000000000-0x000000080000 : "boot"
0x000000080000-0x0000000c0000 : "u_env"
0x0000000c0000-0x000000100000 : "Factory"
0x000000100000-0x000000140000 : "s_env"
0x000000140000-0x000000180000 : "devinfo"
0x000000180000-0x000001f80000 : "firmware"
0x0000004d9b12-0x000001f80000 : "rootfs"
mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
mtd: partition "rootfs_data" created automatically, ofs=0xca0000, len=0x12e0000
0x000000ca0000-0x000001f80000 : "rootfs_data"
0x000001f80000-0x000003d80000 : "alt_firmware"
0x000003d80000-0x000007f80000 : "gdata"
[mtk_nand] probe successfully!
rootfs = 4d9b12 to ca0000
register mt_drv

Isn't it odd that rootfs is starting at an odd address of 4d9b12?

Judging from the offsets, the "rootfs" partition is located within the "firmware" right after a compressed kernel image.

This is something we do in OpenWrt too in order to get the most out of the flash space.
So the kernel(+dtb)/FIT and the squashfs rootfs are packed right next to each other without the usual page alignment "gap". (This is because kernel+rootfs are read-only for the most part and only the
initial-install or later sysupgrade will write into these areas.)

Openwrt uses "mtdsplitter" (see target/linux/generic/files/drivers/mtd/mtdsplit/) for this. So you'll only need to specify a "firmware" partition (the "firmware" is a Magic) and place your kernel+rootfs in this "firmware" partition. The mtdsplit will then automatically create the kernel+rootfs and rootfs_data partitions when booting.

Hope this helps.

(Note: Do you know what rootfs_data is formatted with? It seems you have a ~128MiB of flash and the MT7621-NAND sounds like you have a NAND-Chip. The thing is that rootfs_data makes it sound like Linksys is still using JFFS2 for the volatile files?! This is bad if this is the case. UBI+UBIFS is a much better option for NAND)

Thanks for your expert comments. I have just created the device page and pasted the boot log there. It looks like they do use UBI fs.

Looking at the log, it looks like gdata is UBI fs.