[U-Boot] U-boot partition size information

[Nathan French]

I've got a kilauea-ish board that we've decided needs more room in one
of the flash partitions.  So I took the existing command line:

        Kernel command line: ramdisk_size=65536 root=/dev/ram rw
        mtdparts=fc000000.nor_flash:2M(linux),20M(ramdisk),4M(jffs2),38272k(user),256k(env),384k(uboot) ip=10.2.3.28:10.1.0.65:10.0.0.1::kilauea:eth0:off panic=1 console=ttyS0,115200

And modified it like below (4M -> 8M, 38272k->34176k).  We're not
currently using the user partition, so I just borrowed 4MB from it.

        Kernel command line: ramdisk_size=65536 root=/dev/ram rw
        mtdparts=fc000000.nor_flash:2M(linux),20M(ramdisk),8M(jffs2),34176k(user),256k(env),384k(uboot) ip=10.2.3.28:10.1.0.65:10.0.0.1::kilauea:eth0:off panic=1 console=ttyS0,115200
        
And I get the below error.  I noticed that the device tree (FDT/DTB)
lists some partitions as well that don't exactly match up with the
original parameters, so I ignored that part of the FDT.  Is this ok?
Does Linux ignore the partition information from the FDT when U-Boot
passes partition arguments?

Oh and... well why is the ram0 device complaining when I modify the
flash partitioning?

RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (24576 != 32768) 35815424
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 136k init
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
Warning: unable to open an initial console.
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
...

Thanks,

Nathan French