[U-Boot-Users] bootargs for partitioned nand flash
Hi,
I'm trying to get a 64 MByte nand flash to be partitioned in a 32MB cramfs and 32MB jffs2 partition. In case anyone's curious, I would like the cramfs to be root as it would be a faster mount and its read-only feature.
I tried to do this in the kernel by
static struct mtd_partition partition_info[] = { [0] = { .name = "CRAM", .offset = 0, .size = 32 * 1024 * 1024, .mask_flags = MTD_WRITEABLE, /* force read-only */ }, [1] = { .name = "JFFS2", .offset = 32 * 1024 * 1024, .size = MTDPART_SIZ_FULL, } };
but when I cat/proc/mtd, I get / # cat /proc/mtd dev: size erasesize name mtd0: 04000000 00004000 "rootfs"
so I realise that this is affected by the bootargs passed by u-bootloader which is "bootargs=console=ttyS0 mtdparts=a9m9750:0x4000000@0(rootfs) root=mtdblock/0 rootfstype=jffs2"
How should I passed the bootargs?
Thanks in advance, Terence.
In message OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471@applera.com you wrote:
I'm trying to get a 64 MByte nand flash to be partitioned in a 32MB cramfs and 32MB jffs2 partition. In case anyone's curious, I would like the cramfs to be root as it would be a faster mount and its read-only feature.
All this is off topic here. It has nothing to do with U-Boot.
Also note that a cramfs may fail to work in case there are bad sectors in your NAND device.
so I realise that this is affected by the bootargs passed by u-bootloader
It does not matter which bot loader passes the arguments - it is only a Linux kernel issue.
How should I passed the bootargs?
You might have a look at the CONFIG_JFFS2_CMDLINE config option in U-Boot (see CHANGELOG).
--=_alternative 002CF47148257125_= Content-Type: text/html; charset="US-ASCII"
And NEVER post HTML here!
Best regards,
Wolfgang Denk
Wolfgang Denk <wd <at> denx.de> writes:
In message <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471 <at>
applera.com> you wrote:
Also note that a cramfs may fail to work in case there are bad sectors in your NAND device.
Wolfgang, this might be an off topic here. I have a client requirement to have a RFS like cramfs or squashfs on NAND. If I use the u-boot nand write command to write the cramfs to a MTD partition. How does nand write treat a bad block? I am thinking that if nand write skip to the next block, then I might be able to modify nand read... Or is there a better way?
Thanks, Norman
Hi Norman,
Wolfgang Denk <wd <at> denx.de> writes:
In message <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471 <at>
applera.com> you wrote:
Also note that a cramfs may fail to work in case there are bad sectors in your NAND device.
Wolfgang, this might be an off topic here. I have a client requirement to have a RFS like cramfs or squashfs on NAND.
Check the available documentation on NAND devices. I found this application note to be a real eye opener[1]. Especially the section "NAND Flash is Not a Hard Drive" is a must read. Maybe you reconsider the requirement.
If I use the u-boot nand write command to write the cramfs to a MTD partition. How does nand write treat a bad block?
What part of this section from doc/README.nand is not clear to you?
nand write.jffs2 addr ofs|partition size Like `write', but blocks that are marked bad are skipped and the data is written to the next block instead. This allows writing a JFFS2 image, as long as the image is short enough to fit even after skipping the bad blocks. Compact images, such as those produced by mkfs.jffs2 should work well, but loading an image copied from another flash is going to be trouble if there are any bad block
I am thinking that if nand write skip to the next block, then I might be able to modify nand read... Or is there a better way?
What does the block layer of MTD in linux do? This is a much more interesting question. As far as I can see, this layer will not be able to handle any bad blocks.
Unless I don't see a very clever solution, putting such a filesystem on a flaky substrate like NAND really needs another layer handling the shuffling around - UBI comes to mind here, but I do not have any experiences with it (yet).
Cheers Detlev
[1] http://download.micron.com/pdf/technotes/nand/tn2917.pdf
participants (4)
-
Detlev Zundel -
Norman -
Terence Soh -
Wolfgang Denk