How is mtdparts passed from u-boot to the kernel?

I am running stock (unpatched) u-boot and linux with a custom environment and device tree on a Colibri VF50. I am trying to understand how my kernel is picking up the MTD partitioning, as this isn’t defined in the kernel or my device tree, and I am not passing this information through the kernel command line.

I’ve figured out that the partitioning is derived from the u-boot mtdparts command line. First of all, here is /proc/mtd:

dev:    size   erasesize  name
mtd0: 00020000 00020000 "vf-bcb"
mtd1: 00160000 00020000 "u-boot"
mtd2: 00080000 00020000 "u-boot-env"
mtd3: 07e00000 00020000 "ubi"

and here is mtdparts (and deleting this environment variable does indeed result in an unpartitioned /proc/mtd):

# printenv mtdparts

So far so good … but how does the kernel know this? Not from the command line:

# cat /proc/cmdline 
ubi.mtd=ubi rdinit=/sbin/init root=/dev/ram initrd=0x82100000,0x2eaf4e

I’m failing to find the right documentation, this is clearly part of the hand-off from u-boot to linux.
Is U-boot injecting this information into the DTS? If so presumably it’s somewhere under /sys/firmware/devicetree, and presumably this is documented somewhere?

I’m keen to understand this so I don’t break my system by accident in the future!

So, yes, it is definitely being injected into my in-memory device tree: I find the partitions under /sys/firmware/devicetree/base/soc/aips-bus@40080000/nand@400e0000/nand@0.

So I guess my question reduces to this: which modifications can U-boot make to my device tree, where is this documented, and how do I manage these changes?


U-Boot is patching the device tree with the info from the env variable mtdparts.
Have a look here.


Ok. I see that this is controlled by CONFIG_FDT_FIXUP_PARTITIONS; I guess the “documentation” is this:


overwrite MTD partitions in DTS through defined in ‘mtdparts’

Allow overwriting defined partitions in the device tree blob using partition info defined in the ‘mtdparts’ environment variable.

Do you happen to know if there are any other cases where the loaded device tree can be modified by U-boot?

P.S. I meant and forgot to ask: what is the meaning and use of the vf-bcb partition?

Woo: a quick grep for fixup in U-boot finds a lot; perhaps I’m trying to open a can of worms here.

Are there any other U-boot environment variables I need to watch out for? The temptation to prune my overcomplex printenv output is strong…

On top of the mtd partitioning we add serial number, toradex,product-id and, toradex,board-rev.
Then there are some standard properties which U-Boot patches, among them the mac address, RAM memory layout and others.

AFAIK there is no specific documentation.

The vf-bcb partition is where the bcb is stored. Compare with the ‘NAND Flash Boot’ section in the reference manual.

Which reference manual do you mean? I’m not finding much reference to the phrase "nand flash boot". I’m guessing BCB is “boot control block”? My best guess as to what you mean by “reference manual” is the “VFxxx Controller Reference Manual” downloadable from here?

I guess I already know what I need to know, which is leave it alone!

Yes, I mean NXP’s “VFxxx Controller Reference Manual”.