Do you have a question? Post it now! No Registration Necessary
August 3, 2010, 6:39 am

Hello
I'm working on embedded platform (Broadcom's bcm5358u processor with MIPS
core), where I need extra partitions for the purpose of further upgrade
procedure. The filesystem used is SquashFS, so I modified 'struct
mtd_partition' accordingly, which is passed to MTD related code, and I ended
up with this (dmesg snippet):
Creating 7 MTD partitions on "sflash":
0x00000000-0x00020000 : "boot"
0x00020000-0x00600000 : "bank1os"
0x00188820-0x00600000 : "bank1fs"
0x00600000-0x00be0000 : "bank2os"
0x00788820-0x00be0000 : "bank2fs"
0x00be0000-0x00ff0000 : "app"
0x00ff0000-0x01000000 : "nvram"
#cat /proc/partitions
major minor #blocks name
31 0 128 mtdblock0
31 1 6016 mtdblock1
31 2 4573 mtdblock2
31 3 6016 mtdblock3
31 4 4445 mtdblock4
31 5 4160 mtdblock5
31 6 64 mtdblock6
#cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00010000 "boot"
mtd1: 005e0000 00010000 "bank1os"
mtd2: 004777e0 00010000 "bank1fs"
mtd3: 005e0000 00010000 "bank2os"
mtd4: 004577e0 00010000 "bank2fs"
mtd5: 00410000 00010000 "app"
mtd6: 00010000 00010000 "nvram"
Now I want to be able to mount /dev/mtdblock4 as a temporary storage during
system upgrade, but I can't do this, because it appears that this partition
mtdblock4 doesn't have any FS installed. The kernel image and FS are
integrated in one image, which is flashed down the /dev/mtdblock2 (which is
supplied as root_fs to kernel).
I see only one solution: create a empty squashFS image, write it on
/dev/mtdblock4 and may be it will work as I want (?). Is there a way to,
like, format the partition on the fly, whenever the kernel boots, or it
violates the MTD concepts?
Thanks.
I'm working on embedded platform (Broadcom's bcm5358u processor with MIPS
core), where I need extra partitions for the purpose of further upgrade
procedure. The filesystem used is SquashFS, so I modified 'struct
mtd_partition' accordingly, which is passed to MTD related code, and I ended
up with this (dmesg snippet):
Creating 7 MTD partitions on "sflash":
0x00000000-0x00020000 : "boot"
0x00020000-0x00600000 : "bank1os"
0x00188820-0x00600000 : "bank1fs"
0x00600000-0x00be0000 : "bank2os"
0x00788820-0x00be0000 : "bank2fs"
0x00be0000-0x00ff0000 : "app"
0x00ff0000-0x01000000 : "nvram"
#cat /proc/partitions
major minor #blocks name
31 0 128 mtdblock0
31 1 6016 mtdblock1
31 2 4573 mtdblock2
31 3 6016 mtdblock3
31 4 4445 mtdblock4
31 5 4160 mtdblock5
31 6 64 mtdblock6
#cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00010000 "boot"
mtd1: 005e0000 00010000 "bank1os"
mtd2: 004777e0 00010000 "bank1fs"
mtd3: 005e0000 00010000 "bank2os"
mtd4: 004577e0 00010000 "bank2fs"
mtd5: 00410000 00010000 "app"
mtd6: 00010000 00010000 "nvram"
Now I want to be able to mount /dev/mtdblock4 as a temporary storage during
system upgrade, but I can't do this, because it appears that this partition
mtdblock4 doesn't have any FS installed. The kernel image and FS are
integrated in one image, which is flashed down the /dev/mtdblock2 (which is
supplied as root_fs to kernel).
I see only one solution: create a empty squashFS image, write it on
/dev/mtdblock4 and may be it will work as I want (?). Is there a way to,
like, format the partition on the fly, whenever the kernel boots, or it
violates the MTD concepts?
Thanks.
--
Mark
Mark

Re: create multiple SquashFS partitions

<snip>

Note that squashfs is read-only, so you won't be able to write
anything to it. I suspect you'll want to use something like jffs. Or
if you have lots of RAM to spare, you could use a tmpfs filesystem
rather than needing flash at all.

I haven't tried it with squashfs, but with some filesystems you can
just initialize the entire flash partition with zeros (mfill followed
by fis create if you are using RedBoot). If that works for your
chosen fs, you should be able to fill the /dev/mtdblock4 with zeros
post-boot, prior to issuing the mount command.
Regards,
Steve

Re: create multiple SquashFS partitions

JFFS (actually JFFS2 these days) and YAFFS work with NAND and NOR
flash. That is, any flash which is under the MTD driver. You just
can't use those for flash types which are not directly connected and
therefore are not under MTD, such as SD/MMC/USB flash.
Steve

Re: create multiple SquashFS partitions
steve snipped-for-privacy@hotmail.com writes:

To perhaps clarify this somewhat: The main difference between NAND and
NOR flash from a user's viewpoint is that NOR flash can be used just
like any other memory area being part of the physical memory map of a
system for read accesses while NAND flash chips are actually 'block
devices' and not random-access memory. But this difference is
virtualized away at the mtd layer and anything which uses that just
invokes the read- and write-methods of the virtual MTD device.

To perhaps clarify this somewhat: The main difference between NAND and
NOR flash from a user's viewpoint is that NOR flash can be used just
like any other memory area being part of the physical memory map of a
system for read accesses while NAND flash chips are actually 'block
devices' and not random-access memory. But this difference is
virtualized away at the mtd layer and anything which uses that just
invokes the read- and write-methods of the virtual MTD device.

Re: create multiple SquashFS partitions
Hi Mark.

Yes, you can mix the file system types.
The MTD driver has no involvement in what file system is used. That's
under the control of fs/jffs2 and the like. MTD operates at a lower
level. In fact, there might not even be a file system in some of the
partitions, such as where you kernel image is stored.
Steve

Yes, you can mix the file system types.
The MTD driver has no involvement in what file system is used. That's
under the control of fs/jffs2 and the like. MTD operates at a lower
level. In fact, there might not even be a file system in some of the
partitions, such as where you kernel image is stored.
Steve
Site Timeline
- » [ANN] Free proprietary license for CodeSynthesis XSD/e
- — Next thread in » Embedded Linux
-
- » Embedded Linux Learning Kit
- — Previous thread in » Embedded Linux
-
- » Crosscompiling for ARM: reloc type R_ARM_ABS32 is not supported for PIC - ...
- — Newest thread in » Embedded Linux
-
- » WHO experts weigh in on COVID-19 vaccine dose interval
- — The site's Newest Thread. Posted in » Electronics Design
-