From: Nathan French <nathan.french@onrampwireless.com>
To: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Having trouble using mtdparts kernel command line to repartition flash
Date: Fri, 21 Aug 2009 13:48:03 -0700 [thread overview]
Message-ID: <1250887683.20417.7499.camel@localhost.localdomain> (raw)
I've got a kilauea (PPC405EX) board that we've decided needs more room
in one of the flash partitions. So I took the existing command line
(which came from the dev kit):
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? I'm not expecting the 20M ramdisk portion to be
affected. Also I noticed that the device tree (DTS/DTB) does not
reflect the original partition scheme. Does it need to or is the device
tree ignored when using the mtdparts partitioning? I tried modifying it
to match but didn't seem to make a difference.
Am I missing something here?
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
reply other threads:[~2009-08-21 20:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250887683.20417.7499.camel@localhost.localdomain \
--to=nathan.french@onrampwireless.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox